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International School on 
Foundations of Security Analysis and Design 

18-30 September 2000, Bertinoro, Italy 



Security is a fast growing area of Computer Science, with increasing rele- 
vance to real life applications such as Internet transactions and electronic 
commerce. Foundations for the analysis and the design of security aspects 
of these applications are badly needed in order to validate and prove (or 
guarantee) their correctness. Recently an IFIP Working Group on “Theoret- 
ical Foundations of Security Analysis and Design” has been established (see 
http://www.dsi.unive.it/IFIPWGl_7/ for more details) in order to pursue a 
number objectives, which include the following: 

— to investigate the theoretical foundations of security as an independent dis- 
cipline with firm grounds in logic, semantics, and complexity; 

— to discover and promote new areas of application of theoretical techniques 
in computer security; 

— to make formal methods amenable to the security practitioners, hence in- 
creasing awareness of formal verification techniques for security in the com- 
puter science community at large. 

Hence, the scope of the IFIP Working Group 1.7 encompasses all aspects of 
the fundamental mathematical theory of system specification and verification, 
which shares with IFIP TGI the basic fields of logic (first-order logic, temporal 
logic, epistemic logic), semantics (static analysis, type theory), formal methods 
and related approaches (model-checking, theorem-proving, process algebra), and 
complexity. 

Among the many initiatives promoted and partly founded by the WG 1.7, 
there is also the “International School on Foundations of Security Analysis and 
Design” (FOSAD) held at the Residential Genter of the University of Bologna in 
Bertinoro, with the goal of disseminating knowledge in this critical area, espe- 
cially for participants coming from less-favored and non-leading countries. The 
Residential Genter is an ex-convent and Episcopal fortress that has been trans- 
formed into a modern conference facility with computing services and Internet 
access. Bertinoro lies approximately half-way between Bologna and the Adri- 
atic coast town of Rimini. Bertinoro is perched on the foothills of the Appenine 
Mountains overlooking the Po Valley to the North and the Tuscan-Emilian hills 
to the South. 

The topics covered by the school (see http://www.cs.unibo.it/ aldini/fosad/ 
for more details) included: Security in Programming Languages and Process Gal- 
culi; Mathematical Models of Gomputer Security (e.g. non interference); Logics 
and Models for Security Protocols Specification (e.g. belief logic, strand spaces); 
Gryptographic Protocol Analysis (e.g. by model checking or theorem proving); 




VI 



Foreword 



Cryptographic Protocols at Work (e.g. in electronic commerce); Access Control 
and Personal Identification. The school was composed of eight main courses, 
each one lasting six or eight hours. Additionally, four further courses, lasting 
two hours each, were offered. 

This volume collects six tutorial lectures given at the school. More precisely: 

— Andrew D. Gordon, Microsoft, Cambridge (Nominal Calculi for Security and 
Mobility); 

— Roberto Gorrieri, University of Bologna, and Riccardo Forcardi, University 
of Venice (Classification of Security Properties); 

— Joshua Guttman, Mitre, Bedford, (Security Goals: Packet Trajectories, and 
Strand Spaces); 

— Peter Ryan, CMU, Pittsburgh, (Mathematical Models of Computer Secu- 
rity); 

— Pierangela Samarati, University of Milan (Access Control: Policies, Models, 
Architectures, and Mechanisms); 

— Paul Syverson, Naval Research Lab, Washington, (The Logic of Security 
Protocols). 

The school attracted a lot of people. We received almost 100 applications from 
all over the world. Typical applicants were PhD students, young researchers, 
a few senior researchers in different areas, some industrial researchers, a few 
governmental institution members. We selected 60 participants from 4 continents 
(47 European, 5 Asian, 6 American, 2 African participants), a few more than 
initially planned, due to the enormous pressure of the applicants that firmly 
wanted to take part in the event. All participants will receive this special volume 
of the Springer- Verlag Lecture Notes of Computer Science series. 

We would like to thank all the institutions that have supported the initia- 
tive: EU (High Level Scientific Conferences programme), UNESCO Venice Of- 
fice, Ser.In.Ar., University of Bologna, Fondazione Cassa di Risparmio di Forli’. 
Moreover, the school was held under the auspices of the European Association of 
Theoretical Computer Science (EATCS - Italian Chapter), International Federa- 
tion for Information Processing (IFIP ~ WG 1.7), European Educational Forum. 
Finally, we would like to warmly thank the local organizers of the school, espe- 
cially Alessandro Aldini, Andrea Bandini, Mario Bravetti, and Roberta Poggi. 
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Mathematical Models of Computer Security 



Peter Y. A. Ryan 
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Abstract. In this chapter I present a process algebraic approach to the 
modelling of security properties and policies. I will concentrate on the 
concept of secrecy, also known as confidentiality, and in particular on 
the notion of non-interference. Non-interference seeks to characterise the 
absence of information flows through a system and, as such, is a funda- 
mental concept in information security. 

A central thesis of these lectures is that, viewed from a process algebraic 
point of view, the problem of characterising non-interference is essen- 
tially equivalent to that of characterising the equivalence of processes. 
The latter is itself a fundamental and delicate question at the heart of 
process algebra and indeed theoretical computer science: the semantics 
of a process is intimately linked to the question of which processes should 
be regarded as equivalent. 

We start, by way of motivation and to set the context, with a brief 
historical background. A much fuller exposition of security policies in 
the wider sense, embracing properties other than secrecy, can be found 
in the chapter by Pierangela Samarati in this volume. We then cover 
some elements of process algebra, in particular CSP (Communicating 
Sequential Processes), that we need and present a formulation of non- 
interference, along with some more operational presentations of process 
algebra, including the idea of bi-simulation. I argue that the classical 
notion of unwinding found in the security literature is really just bi- 
simulation in another guise. 

Finally, I propose some generalisations of the process algebraic formula- 
tions designed to encompass a richer class of policies and examples. 



1 Background 

This chapter presents a process algebra based framework in which we can ex- 
press and analyze security requirements at an abstract level. I hope that the 
reader will come away with the impression that such an approach is well suited 
to formulating security properties. Many issues that have proved problematic 
in the formulation of, for example, secrecy in information processing systems, 
become much clearer when viewed in a process algebraic style. Many insights 
and results from the process algebra community turn out to be highly relevant 
in the context of information security. On the other hand, information security 
presents a number of challenges to current theory and so should help stimulate 
advances in theory. 
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The term security is often used to cover a multitude of requirements, in 
particular: 

— Secrecy (confidentiality) 

— Integrity 

— Availability (e.g., resilience to denial-of-service attacks). 

By secrecy or confidentiality I mean, informally, that information can only be 
acquired by agents or processes entitled to such access. By and large I will regard 
the task of a policy to be to define when access should be allowed or denied. 
Integrity, roughly speaking, will mean that the correctness of data is ensured: i.e., 
it can only be established or modified by agents or processes entitled to influence 
the values of the data. Availability typically means that access to information 
and services to agents with the right to them is maintained in a timely and 
dependable manner. 

Pierangela has given the background to these concepts in her chapter of this 
volume so we will not dwell on the various flavours that exist in the security 
literature. For the most part I will concentrate on secrecy for these lectures but 
I will touch on the other requirements. Indeed, to some extent at least, other 
requirements can be captured in a rather similar framework as variants of non- 
interference. 

There has been much debate in the security literature as to what exactly 
is meant by the terms security model or security policy and indeed what, if 
any, is the distinction. I do not propose to enter such debate in these lectures, 
but refer the interested reader to the excellent and lucid writings of McLean, 
for example [57], on this and the subject area in general. For the purposes of 
these lectures I will take the attitude that the purpose of a policy is to state 
what information flows are to be allowed and which are to be prevented. More 
generally a policy will state what privileges are accorded to which agents. I will 
regard a model as being a mathematical framework in which we can precisely 
characterise the properties of interest, in particular that of secrecy, i.e., the 
absence of certain information flows. 

Another much debated question is that of whether a “correct,” Platonic no- 
tion of security, or at least secrecy, exists. Again I will avoid being drawn into the 
rather philosophical aspects of such discussions. We will see later, however, that 
even the apparently rather well focussed question of characterising information 
flows, and in particular their absence, in a system is surprisingly delicate, but 
for precise mathematical reasons rather than philosophical ones. 

In these lectures I am principally concerned with presenting definitions se- 
curity properties such as secrecy. Such definitions are of little use if we do not 
have ways to demonstrate that actual designs and systems meet the defintions. 
I will discuss some of the issues involved in going from the high-level definitions 
towards implementations. This turns out to be distinctly non-trivial. Step-wise 
development techniques are well established for so-called safety properties but 
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it is well known that security properties tend not to be preserved by such tech- 
niques. Safety properties typically amount to assertions that a system will not 
perform such and such an undesirable behaviour. As we will see later, secu- 
rity properties are far more subtle and cannot be captured by simply outlawing 
certain behaviours. 

The next two sections provide some motivation for the use of mathematical 
models. Section 4 gives a brief overview of the historical development of models 
of computer security. This will help to put the central theme, the concept of 
non-interference, in context. Section 5 presents the Goguen-Meseguer formula- 
tion of non-interference along with some discussions of the limitations of this 
formulation. This is usually cited as the primary reference for non-interference 
although there is some prior work due to Cohen and Feiertag. This is followed 
by a brief introduction to process algebra, in particular CSP, which will be used 
to give more up-to-date formulations of non-interference. Finally I present some 
generalisations of these formulations and topics for further research. 



2 Mathematical Models 

Before we launch into descriptions of mathematical models, a few words are in 
order on why such models are needed at all. The purpose of (mathematical) 
models is to provide abstract descriptions of a more complex reality. The models 
will typically ignore many details of the real artifact in order to render them 
understandable and amenable to analysis. Care has to be taken to ensure that 
such abstractions are not so drastic as to remove any semblance of reality. 

Usually we are only interested in certain aspects of the real artifact that are 
wholly or largely independent of many of the details. For example, in thermo- 
dynamics physicists study the behaviour of a gas in a box. Suppose that the gas 
comprises n molecules, then the state of the gas is represented by a point in a 6n 
dimensional phase space. However we are not remotely interested in the exact 
point in the phase space the gas actually occupies. Even if we could accurately 
determine this point it would actually tell us nothing of interest. It is enough 
for most purposes just to consider the state of the gas to be a function of three 
parameters: temperature, volume and pressure and to study the relationship be- 
tween these. The equations of motion on the phase space lift to relations between 
these parameters. 

Similarly in computer science we are dealing with extremely complex arti- 
facts, many of whose details are of no interest to us or are unobservable. Again 
we use mathematical models which, by their very nature, abstract much of the 
extraneous detail or are suitably constructed to allow us to make abstractions 
as appropriate. In these lectures we will be concentrating on process algebras as 
our mathematical framework and we will see that these give rise rather natu- 
rally to a representation of systems that corresponds to what is observable by 
some outside observer. Process algebras also lead to a number of very natural 
and powerful abstraction operators. We will see, for example, how the notion of 
secrecy leads to equivalences on the state space of a system rather analogous to 
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the way a thermodynamical system is factored by equivalences of temperature, 
pressure and volume. 

In short, the use of mathematical models allows us to introduce simplicity, 
to borrow a phrase from Abrial [76]. We can then deploy all the usual math- 
ematician’s tricks of abstraction, modularisation, symmetry, etc. to reduce the 
problem to mind-sized chunks. All the while we have to be careful that we have 
not simplified too much. This is an ever present danger, especially for security, 
where the old dictum: “the devil is in the detail,” is particularly true. 

Another beauty of mathematical models is that they are completely at your 
mercy: you can do what you like with them, up to requirements of consistency. 
You can change parameters with an ease that would be impossible with the 
real thing or even a physical mock up. You can perform Gedankenexperimente: 
thought experiments that would be impossible in reality, along the lines of Ein- 
stein’s riding a light beam. 

Another motivation for models is that they allow us to move from an abstract 
representation gradually, in a step-wise fashion towards an implementation. The 
hope is that by making the steps reasonably modest we ensure that the complex- 
ity of our manipulations and proofs is kept manageable throughout. This tends 
to be rather easier said than done, especially for security, but it is nonetheless 
a worthy and sensible goal. 

We also need to bear in mind that absolute security is probably a theoretical 
impossibility and certainly a practical impossibility. Ultimately we need to aim 
to provide adequate levels of security against probable threats, enough for to 
ensure that the cost to the attacker of launching an attack outweighs the benefits. 
In the world of physical security people have long known how to rate safes in 
terms of the time they can resist certain types of attack. So, you choose the 
appropriate safe in terms of its resistance to attack and in terms of the likely 
value of its contents. Such ratings can be blown away by a new mode of attack 
and the history of safe design has been a game of cat and mouse between the safe 
designers and the safe crackers. When a new style of attack is invented, a few 
safes get blown, and new designs are deployed. 

The story is rather similar in the information security world, but there are 
differences. The game is a far more complex one: the systems in question are 
vastly complex and the styles of attack vastly more diverse. Often the stakes are 
much higher. If we are concerned with critical infrastructures for example, we 
can’t just insure everything with Lloyd’s of London and upgrade our defences 
after a cyber terrorist has taken the whole system out. 



3 Formal Models and Methods 

A few words are also in order on the nature and utility of formal models and 
formal methods. The idea of formality in mathematics goes back a long way, 
to around the time of Hilbert. The motivation was to flush out implicit and 
unstated assumptions in proofs. Most rigorous, journal-style proofs will involve 
quite large steps whose justification involves understanding and insight into the 
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problem domain. Typically, the detailed justification of such steps can be readily 
filled in by a competent mathematician. Occasionally errors show up later or, 
more usually, it is found that the justification actually requires some additional 
assumption not explicitly stated in the original proof. The delightful book “Proofs 
and Refutations” , [42] , by Lakatos illustrates this process beautifully by tracing 
“proofs” of the Euler formula relating the number of edges, vertices and faces of 
polyhedra. Early “proofs” were published only for counter-examples to be found 
later. Closer examination revealed that the “proofs” actually depended on certain 
unstated assumptions, assumptions that were violated by the counter-examples. 
Thus, for example, it had unwittingly been assumed that the polyhedra were 
convex and had a simple topology, i.e., genus zero. The counter-examples, Kepler 
stars or toroidal polyhedra, etc., violated these conditions. 

This is rather troubling and raises the question: when is a proof a proof? 
The notion of a formal system and a formal proof is an attempt to answer 
this question. A formal system comprises a finite set of axioms along with a 
finite set of inference rules. A theorem is a statement that can be reached from 
the axioms by finite application of the rules. No further insight or creativity is 
admitted other perhaps than some ingenuity in discovering the right sequence 
of application of rules. In principle, then, any theorem is checkable in a purely 
mechanical fashion and there is no way for implicit assumptions to slip into the 
process. 

Why is all this of interest in systems engineering? Why is it not enough 
just to use rigorous pen-and-paper proofs, for example? There seem to be two 
motivations: again, the urge to flush out all unstated assumptions and, secondly, 
to introduce the possibility of mechanised proofs using automated tools. Are 
these valid motivations? The answer seems to be: sometimes yes. Sometimes 
the design of a system or component is so critical that it really is crucial to 
eliminate the possibility that unrecognised and flawed assumptions could creep 
in. Sometimes having an automated tool really does help, in the sense that it 
reduces the amount of work and/or increases the resulting level of assurance. 
But it is essential to use the right tool in the right place. The essential question 
is, as Bob Morris Sr., has phrased it: “Where do I put my extra five bucks of 
verification money?” 

Unfortunately, the history of formal methods is littered with instances of 
a compulsion to perform a mechanised proof even where this has been vastly 
expensive and has added little or nothing of benefit. You really have to ask 
yourself why you are attempting to prove something and, in particular, why 
with a mechanised proof. The validity of the result has to matter. If you are after 
insight into why the result holds, you are probably better off with a rigorous, 
pen-and-paper proof. Often the kinds of theorems that crop when performing 
a refinement as proof obligations (or opportunities as Jim Woodcock prefers 
to call them) involve rather tedious and error-prone case enumeration. This is 
the kind of thing theorem-provers or model-checkers are actually rather good 
at. For the more interesting theorems the tools can all too easily get in the 
way. Mackenzie, for example, discusses such issues in depth [50]. Often the mere 
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process of thinking about how to cast a design in a form ripe for analysis reveals 
ambiguities, flaws and insights long before any proofs are actually attempted. 

We hasten to reassure the reader that none of the results presented here have 
been subjected to the ignominy of mechanical proof. 



4 A Brief History of Security Models 

I will concentrate on the concept of non-interference and related models of se- 
curity, but to help put this in context I give a very swift overview of the early 
evolution of computer security models in this chapter. 

The topic of security models goes back some 30 years, starting with papers by 
Lampson, for example, that presented ways of formalizing access controls [43]. 
These models comprised a set of subjects S, objects O and access modes A. 
From a security point of view each state of the system corresponds to an access 
control matrix M whose rows correspond to the subjects, and columns to objects. 
Entries in the matrix are subsets of A and represent the allowed access of the 
subject to the object. Various rules constrain how states can evolve, i.e., how 
the entries of the matrix can be updated. 

Such early work was based on analogies with the existing policies and mech- 
anisms for the pen-and-paper world. The early work was also very much inspired 
by (or perhaps more accurately, funded by) the military/government environ- 
ment. 

In the pen and paper world, we traditionally have the notions of classified 
files and cleared individuals. A simple access control policy is then formulated 
in terms of these classifications and clearances. Thus a file might be classified 
secret and so only accessible to someone with secret clearance or higher. The 
traditional mechanisms for enforcing such policy might be a trusted registrar 
who would check the clearance of anyone requesting a particular file and who 
will only hand it over after the clearance has been verified. 

Classification and clearances, that we will refer to collectively as security lev- 
els, are typically organised in a lattice structure. A particularly simple example 
is a linear hierarchy: 



Top secret 
Secret 

Confidential 

Unclassified 

Each element of this hierarchy is said to dominate those below it, as well as 
itself. You are allowed to view a file if your clearance dominates the classifica- 
tion of the file. Thus someone with Secret clearance is allowed to view Secret, 
Confidential or Unclassified files but not Top secret, for example. 
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More elaborate, non-linear lattices representing partial orders are possible 
and indeed common, at least in the military world. These correspond to the 
notion of compartmentalized information and the need to know principle. Thus 
a file might carry not only a classification but also a so-called caveat. For example, 
NATO-Secret, UK-Secret etc. 

The lattice might then take the form: 

Top secret 

NATO Secret - UK Secret 
Confidential 
Unclassified 

NATO-Secret and UK-Secret are incompatible and so someone with UK- 
Secret would not be entitled to view a NATO-secret file and vice versa. Someone 
with Top Secret could view both. Such lattices form the basis of the so-called 
Multi-Level-Secure (MLS) policies that were prevalent in the early work in com- 
puter security and provide a convenient way to define which information flows 
are deemed acceptable and which unacceptable. 

Early models of computer security sought to map such policies and mech- 
anisms across into the information technology world. The policies map across 
reasonably cleanly, though even here some subtleties do arise which we will re- 
turn to shortly. Mapping the mechanisms proves to be distinctly tricky. In the 
pen-and-paper world the means of access to files was pretty simple: you wandered 
over to a registry and persuaded Miss Moneypenny that you had the appropri- 
ate clearance to view a particular file. For distributed information processing 
systems there is a far richer set of modes and mechanisms for accessing data and 
the controls on such access are quite different. Also, access may not be so direct 
but might be mediated by various intermediate programs. 

4.1 The Bell and LaPadula Model 

The model proposed by Bell and LaPadula, (BLP), is one of the earliest and 
best known models [2]. It is embodied in the famous Orange Book put out by 
the NCSC (National Computer Security Centre), a branch of the NSA (National 
Security Agency) [15]. The Orange Book was the first attempt to establish sys- 
tematic criteria for the evaluation of secure systems and products. 

BLP is fairly straightforward and intuitive and is a rather natural analogue 
of MLS policies of the pen-and-paper world. I give a somewhat simplified version 
here; more formal and complete descriptions can be found in [29], for example. 

The model comprises a set of subjects S and objects O. Subjects are thought 
of as active, either principals or processes acting on behalf of principals, whilst 
objects are passive, e.g., files. We suppose that a lattice L of security levels has 
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been defined along with a mapping C from 6” U O into L that assigns a clear- 
ance/classification to each subject/object. For simplicity we will suppose that 
there are just two modes of access: read and write. The information-flow policy 
is now captured by enforcing two rules: 



The Simple Security Property : 

A subject s is allowed read access to an object o if and only if C{s) dominates 
C{o). 

That is, a subject is allowed to read only objects whose classification is dom- 
inated by its clearance. In particular a subject cannot read an object of higher 
classification, a requirement often referred to as no read up. 



The * Property : 

A subject s is allowed write access to an object o if and only if C{o) dominates 
C{s). 

That is a subject is not allowed to write to an object whose classification is 
lower than its clearance, i.e., no write down. 

Assuming that read and write really are the only modes of access to objects 
and, furthermore, that they really are one-way information flows in the direction 
we would intuitively expect, then we see that together these rules ensure that 
information cannot flow downwards through the lattice. Information can flow 
upwards. 

Such a policy is referred to as a mandatory access control (MAC) policy. 
Subjects are not allowed any discretion with respect to these rules or to the clas- 
sifications assigned to objects. Another class of access policies, in which subjects 
are accorded some discretion, can be constructed. Such policies are referred to 
as discretionary access control (DAC) policies. They might permit, for example, 
the owner or creator of a file some discretion as to what classification to assign 
it or to whom he wishes to grant access. A more elaborate version of BLP can 
be used to formulate DAC policies but this will not concern us. See Pierangela’s 
chapter for more on this. 

In practice the MLS model above is too rigid for real environments. In the 
pen-and-paper world there are typically rules and mechanisms allowing excep- 
tions to the strict MLS access rules. You might, in some operational circum- 
stances, want to allow a certain agent access to a file to which he would not 
ordinarily have access according to the MLS rules. Alternatively there may be 
reasons to lower the classification of a file, perhaps after some period has elapsed 
after which its contents are no longer deemed sensitive. Such exceptions would 
typically be handled by a security officer. 

In the BLP model the handling of such exceptions are assigned to so-called 
trusted subjects. Exactly how such trusted subjects are implemented and indeed 
exactly what the term trusted means here has been the subject of much debate. 
The issue will crop up again when we come discuss intransitive non-interference. 
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4.2 The Harrison-Ruzzo-Ullman Model 

The model proposed by Harrison, Ruzzo and Ullman (HRU) is also based on 
Lampson’s access-control-matrix framework, but allows a far richer set of prim- 
itives for updating the state than for BLP [32]. In particular, subject to precon- 
ditions on the state, entries in the matrix can be added or removed, and indeed 
rows and columns can be added or deleted (corresponding to the creation or 
deletion of subject and objects). In effect we have an elaborate, conditional 
rewriting system. Rather unsurprisingly then we rapidly hit against various un- 
decidablity results: in general establishing whether a certain state can be reached, 
i.e., whether a certain access can be granted, is undecidable. 

BLP sacrifices flexibity and genericity for simplicity and decidability. Ques- 
tions of whether a flow from a particular object to a particular subject is per- 
mitted can be immediately answered by simple comparison of their classification 
and clearance, ignoring for the moment the actions of trusted subjects. 

4.3 Chinese Walls 

Chinese walls policies arise naturally in a commercial setting, for example, in 
a consultancy Arm. The Arm will consult to various clients. We want to ensure 
that any given consultant, C say, does not gain access to sensitive information of 
two competing clients, A and B say. This is enforced by stipulating that should C 
get access to A's files he should subsequently be barred from access to B's files 
and vice versa. In effect we need to enforce appropriate mutual exclusion rules 
for clients with potentially conflicting interests. 

Such policies can be formulated in the HRU model and can be modelled in 
the MLS framework as long as we allow for dynamic clearances, see [22,81]. Here 
accesses evolve: initially C has access rights to H or 5 but as soon as he exercises 
his right to A' s files, say, then his right to B' s is deleted, or vice versa. Notice, 
however, that rights are monotonically non-increasing. 

Brewer and Nash proposed introducing such policies and models into com- 
puter security [5] . They are an instance of a more general class of policies known 
as dynamic separation of duties policies. Here a principal can take on certain 
roles, but there are certain mutual exclusions between roles. Thus if he takes 
on a role as a bank teller he cannot also countersign cheques, for example. The 
purpose of such rules are to try to prevent abuse of privilege by ensuring that 
a misdemeanor cannot be performed by a single individual and would require 
collusion. 

4.4 The Clark Wilson Model 

Clark and Wilson propose a significantly more elaborate framework designed to 
capture policies of relevance in a commercial environment [9] . This embraces not 
only confidentiality and integrity requirements but also notions of separation of 
duties and well-formed transactions. Rather than the access-control lists or ma- 
trices of the previous models they use access-triples. These define the programs 
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(well-formed transactions) that a user may invoke to access certain data objects. 
Good references for further reading are: [46,86,23]. 

4.5 The Biba Model 

Thus far we have only considered secrecy, or if you prefer, confidentiality. In some 
applications, ensuring the integrity of data is also often of concern. A simple form 
of integrity policy was proposed by Biba which is really just a dual of BLP [4]. 
The elements of the model are identical to BLP except that we invert the simple 
and * properties and think of the lattice as representing integrity levels rather 
than security levels. The effect then is to ensure that information cannot flow up 
in terms of the integrity lattice. In other words a low-integrity subject cannot 
alter an object whose integrity level is higher. 

4.6 Drawbacks of BLP 

BLP has the advantage of being intuitively appealing and simple to understand. 
The fact that it is so simple and intuitive, however, conceals a number of sub- 
tleties and problems. 

Firstly it relies heavily on our intuition as to the meaning of the terms read 
and write. These are not given precise, let alone formal, definitions but it is clear 
that it is being assumed that they constitute one-way flows of information. Thus 
if Anne reads a file X we are assuming that information only flows from X to 
Anne and that there is no flow from Anne to X . Similarly if Anne writes to X 
we are assuming that there is no flow from X to Anne. This sounds plausible 
and in line with our intuitive undestanding of the terms. However, interactions 
are rarely one-way, particularly in a distributed context. Communication usu- 
ally involves protocols with messages passing back and forth to establish and 
maintain channels. 

Let us take an extreme example: devices like the CESG One- Way-Regulator 
or the NRL Pump, [40], were developed to enforce one way flow of information, 
from L to H, say. Even these devices require some regulatory signals flowing 
from H to L to avoid buffer overflows and other problems. Thus, even here, 
there is two way flow of information, albeit of a very low bandwidth in one 
direction. 

Our intuitions can be deceptive. Consider an even more extreme example. 
We could completely invert the usual semantics of read and write. This would 
give an entirely consistent BLP-style model but systems that satisfied it would 
be the antithesis of what we had in mind for a system that maintains secrecy. 
In fact, essentially this occurs when we try to define the notion of integrity as 
in the Biba model above. The saying “people in glass houses shouldn’t throw 
stones” makes good sense, but then so does: “people who live in stone houses 
shouldn’t throw glasses.” 

A further difficulty stems from the fact that when we come to map the 
model down onto a real system we have to try to identify all the channels by 
which subjects can access objects. In a complex system it is clearly difficult to 
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be sure that all such channels have been identified. This, along with the issue 
raised earlier-that even supposing that we have identified all the channels we 
may still have failed to model them accurately-makes analysis very difficult. 
Thus there may easily be information flows in the system that we fail to identify 
and that might then allow illegal information flows to go undetected. Arguably 
things are better in an object-oriented framework in that the methods should 
constitute the full set of access modes to an object. In fact, closer examination 
of implementations reveals other access channels not explicitly represented at 
the object-oriented level of abstraction. 

Consider a further example: suppose that a user with a low clearance requests 
to create a file of a given name and suppose that a highly classified file of the 
same name already exists. The system might well reply to the request with 
a “request denied” or, arguably worse still: “request denied, file of that name 
already exists.” This results in an information flow from H to L. It may not be 
a particularly useful flow as it stands but it does represent a channel that could 
potentially be exploited by some malicious code executing at the high level to 
signal to a low process. Such malicious code is referred to as a trojan horse. 

Such channels are well known and standard solutions to this particular prob- 
lem have been proposed-for example, using poly-instantiation: allowing a file of 
a given name to have instantiations at several security levels. However, it is also 
clear that the system may well harbour many other, possibly far more subtle 
flows of this kind. Such channels are known as covert channels and they typically 
arise from the sharing of resources. 

The traditional reaction to such problems is to perform covert channel anal- 
ysis. Conceptually, the known channels are severed and the system is then stud- 
ied to see what channels across security-relevant boundaries remain, [41,54,55]. 
These can either be eliminated or, if they are difficult or impossible to elimi- 
nate, then their channel capacity can be limited to an acceptable level. Thus, 
for example, random delays could be introduced on response signals to intro- 
duce noise and so lower the channel capacity, see [65] for example. This tends to 
have a tradeoff in terms of performance but such tradeoffs are all too familiar in 
security in any case. 

Further objections to BLP have been raised, for example McLean’s System Z 
but these need not concern us here [58] . BLP stands as an important and seminal 
work in the area of security models and indeed continues to play a useful role in 
the design and evaluation of secure systems. In the next section we will present 
a radically different approach to modelling computer security that attempts to 
address some of these objections: the notion of non-interference. 

5 Non-interference 

5.1 Goguen Meseguer 

In response to the concerns raised about BLP and access control style models 
in general, Goguen and Meseguer in, based on some earlier work of Feiertag and 
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Cohen, proposed the idea of non-interference [26,27,18,11]. It can be thought of 
as an attempt to get to the essence of what constitutes an information flow in 
a system and, more to the point, how to characterise the absence of any flow. In 
this sense it resides at a more abstract level than the access-control models and 
can be thought of as providing a formal semantics to the one-way-flow intuition 
behind terms like read and write. In particular, it abstracts completely from the 
inner workings of the system in question and formulates the property purely in 
terms of user interactions with the system interfaces. 

The underlying idea will be familiar to anyone with a mathematics back- 
ground as it is really a reworking in the context of simple model of computation 
of the standard device for characterising a function’s independence with respect 
to a particular variable. 

The model of computation assumed, at least in the original formulation, is 
a rather simple one. In particular it assumes that all computations are deter- 
ministic. In particular the outputs are a simple function of the state and the 
input. That is, given a state along with an input the resulting output is unique 
and well defined. We will come to non-deterministic systems a little later. Non- 
interference seeks to formalise the intuition that the interaction of high-level 
users with a system S should not influence the interactions of low-level users. 
We will paraphrase the original formulation to make the transition to later ma- 
terial a little smoother. 

Histories of user interactions with the system will be recorded as traces, i.e., 
sequences of actions. We suppose that the set of users of the system is partitioned 
into two sets: high users and low users. We suppose further that the high and 
low users interact via separate interfaces and, in particular, low users cannot 
directly observe high actions. The whole point is to examine how much a Low 
user can infer about High actions purely from his (low’s) interactions with the 
system. Clearly if he can directly observe the High actions the whole exercise 
becomes rather futile. 

Notice that we will be assuming that we know the exact design of the system 
and, perhaps more importantly, that any hostile agents have a complete under- 
standing of the system design. In practice neither we nor the hostile agents will 
have such a full understanding but it is a safe assumption to make: the less 
hostile agents know about the system design the less precise the inferences they 
can make. As with cryptography, we should not seek security through obscurity. 

In accordance with the original formulation we will also assume that actions 
are partitioned into inputs and outputs. For the moment we will put aside the 
question of what the semantics behind this distinction might be. Intuitively we 
are thinking of inputs as being wholly under the control of the user, and outputs 
as wholly under the control of the system. This is similar to the BLP use of read 
and write. 

We now think of the system as a finite state machine described by a function 
that, given a state and an input, returns a transition to a new state and an 
output. Given that we are assuming the system to be deterministic this really is 
a function, i.e., the state transition and output associated with an initial state 
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and input are uniquely defined. Furthermore, assuming a unique starting state 
of the system, we have a one-to-one correspondence between traces and states 
and so we can identify states with traces. 

We now restrict the range of the output function to just outputs visible to 
Low. Thus: 

Outputh{S , tr, i) 

gives the Low output from system S when input i is applied to the state 
corresponding to trace tr. 

The final piece of plumbing that we need is the notion of the purge of a trace. 
Informally, purgeni takes a trace and returns a trace with all High inputs, de- 
noted HI, removed. 

A system S is said to be non-interfering from High to Low iff: 



V tr S /*, c € I •Outputi,{S, tr, c) = OutputL{S , purgeHi{tr) , c) (I) 

In other words, for any possible history of inputs to the system and next 
input, the output visible to Low will be the same as if we had stripped out 
all the High inputs. Thus, changing High inputs leaves Low’s view of the sys- 
tem unchanged. This is analogous to the standard way of defining a function’s 
independence with respect to one of its variables. 

It might seem that we have lost generality by assuming that the alphabet of 
the system is partitioned into High and Low. In fact we can deal with more gen- 
eral MLS-style policy with a lattice of classifications by a set of non-interference 
constraints corresponding to the various lattice points. For each lattice point I 
we define High to be the union of the interfaces of agents whose clearance dom- 
inates that of 1. Low will be the complement, i.e., the union of the interfaces 
of all agents whose clearance does not dominate that of 1. Notice also that we 
are assuming that we can clump all the high-level users together and similarly 
all the low-level users. There is nothing to stop all the low users from colluding. 
Similarly any high-level user potentially has access to the inputs of all other high 
users. We are thus again making a worst-case assumption. 

Non-interference takes a very abstract view of the system, effectively treating 
it as a black box and formulating the property purely in terms of its external 
behaviours. This has advantages and disadvantages. It means that the definition 
is wholly independent of the details of the system, so, for example, we don’t have 
to worry about what exactly are the internal information- flow channels. On the 
other hand its abstractness means that it is very remote from real implementa- 
tions. 

A further aspect of reality that has been abstracted away is time. Time simply 
does not appear in the definition or the underlying model of computation. We 
are, in effect, assuming that any adversaries have no way of observing the timing 
of actions. Similarly we have abstracted away from any issues of probability and 
are really just thinking in terms of what events are possible. We are thus working 
in what is sometimes referred to as a possibilistic framework. This is, of course, 
wholly unrealistic, but we have to start somewhere. We will discuss later how 
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one might extend the work presented here to address questions of time and 
probability. 

Notice that non-interference is asymmetrical: we are saying nothing about 
how Low events might influence High outputs. Thus information is allowed to 
flow from Low to High. This is typically what we want for an MLS style policy. 

Non-interference side steps the problems that BLP and other models have 
with covert channels, but does so at the expense of working at a very high level 
of abstraction. Leaving aside questions about input/output distinctions, non- 
interference will capture covert channels. Indeed the motivation for the approach 
was in large part to address the covert channel problem. In particular it addresses 
the possibility that a high user or process may deliberately try to signal to a low 
user. 

Note that non-interference is really about characterizing the absence of causal 
flows rather than information flows. Absence of causal flow implies absence of 
information flow but there may be situations in which we have a causal flow 
without an associated flow of information. The canonical example of this is an 
encrypted channel. Here a secret plaintext will influence a ciphertext that is 
communicated over open channels: altering the plaintext input will alter the 
corresponding ciphertext output and so, naivly at least, non-interference is vi- 
olated. However if the encryption algorithm is sufficiently strong, keys are not 
compromised etc, then we can think of this as not representing any information 
flow from classified to unclassified. We are ignoring for the moment questions of 
traffic analysis. Being sure that such a causal flow doesn’t harbour some subtle 
information flow is very delicate and brings in considerations of cryptanalysis 
amongst other things. There are a number of delicate issues here and we will 
return to this point later. 

5.2 Unwinding 

Goguen and Meseguer also introduce the notion of unwinding a non-interference 
property. As it stands, non-interference is not very useful from a verification point 
of view as it involves quantification over all possible histories of the system. It 
is defined purely in terms of the system’s interactions with the environment 
and without any reference to its internal construction etc. It thus constitutes 
an elegant and abstract definition is not easy to verify directly. Given a black 
box system, to determine if it obeys the non-interference property we would 
be reduced to attempting exhaustive testing, clearly an impossibility. In order 
to render the verification tractable we are forced to assume some (minimal) 
structure on the state of the system. 

The idea of unwinding is to replace the original formulation with conditions 
on state transitions. It is analogous to the standard technique of defining an 
invariant that can then be used to prove a property of all reachable states via 
a structural-induction-style argument. 

A few remarks are in order: it is necessary to introduce an equivalence re- 
lation over the states of the system. This is the relation induced by the purge 
function along with the correspondence between traces and states. Two traces 
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are regarded as equivalent if they have the same purges, i.e., are identical in 
their low-level actions and high outputs. 

Unwinding is now stated as a pair of rules. A system S is non-interfering if: 



y Si, S 2 € traces{S), fli, 02 € A 

• purgemiai) = purgemM A Si k. S 2 ^ S[ k. S 2 (2) 

where denotes a state reached from after the action ai and similarly 
for 52. A denotes the full alphabet of S, i.e., inputs and outputs. Thus A = lUO 
and: 



V 5i « S 2 and\/ a S / • OutputL{Si, a) = Output l{S 2 , a) (3) 

The effect of the first rule is to ensure that the equivalence on the state space 
of S is exactly that induced by the purge of the traces. A simple induction on the 
length of traces along with the one-to-one correspondence between traces and 
states (given that S is deterministic) establishes this. That these together imply 
the original property now follows from this observation along with the second 
rule. In this simple context of a deterministic system it is also straightforward 
to show that these rules are necessary. Things become much more interesting 
when we extend such results to the non-deterministic context later. 

5.3 Non-interference Is Not a Trace Property 

An important observation is that non-interference is not a trace property, that 
is, it cannot be framed simply as a predicate on traces. More precisely, in or- 
der to determine whether a system satisfies non-interference we cannot examine 
it trace by trace to determine whether each trace satisfies a certain predicate. 
Many useful system properties can be stated as such predicates, so-called safety 
properties. These often arise in specifying safety-critical systems where we are as- 
serting that certain undesirable behaviours should not be allowed, in which case 
we can formulate a predicate whose characteristic class is equal to, or perhaps 
is a subset of, the set of acceptable behaviours. 

Non-interference is a property of the space of behaviours. It is really asserting 
that if certain behaviours can occur then it must be the case that other, related 
behaviours must also be possible. Take a trivial example. Suppose that an allowed 
behaviour is h followed by I, with h a High action, I a Low action. If the system 
is to be non-interfering then it must also be possible for just the I to occur 
without the prior h event. Whereas a trace property can be expressed as a set 
of acceptable behaviours, non-interference must be expressed as a set of sets of 
behaviours. 

Conventional refinement techniques are designed to handle safety-style prop- 
erties. A system Q is said to refine P, roughly speaking, if the allowed be- 
haviours of Q are contained in P. A consequence of this observation is that 
non-interference tends not to be preserved by (conventional) refinement. This 
will be discussed more fully later. 
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5.4 Relationship to Bell LaPadula 

It has been claimed that BLP and non-interference are equivalent, [31] for exam- 
ple. The proof depends on some rather strong assumptions about the system’s 
commands and their correspondence with the access modes of the model. In 
general it is difficult to establish such a firm correspondence. On the other hand 
there is a sense in which BLP can be viewed as a mapping of a non-interference 
property to an implementation architecure. This mapping is necessarily rather 
informal, given the lack of precise semantics of BLP and the difficulty in identi- 
fying all internal channels of information flow in the actual architecture. 

There are some interesting issues here: in moving from a non-interference 
formulation to an access-control formulation like Bell LaPadula we are some- 
how moving from a non-trace property to a trace property. The step involves 
introducing assumptions about the architecture and the access modes, etc. In 
effect we are mapping the abstract state space and equivalence relations onto 
the architecture in question. In particular, equivalences at the abstract level will 
typically correspond to states of the system that are indistinguishable under cer- 
tain projections, for example, in certain pieces of memory. This is discussed in 
some detail by Rushby [74]. Certain issues remain however. For example in [21] 
it is shown that an access monitor that obeys the BLP rules can still leak infor- 
mation as a result of deadlocks. We will not discuss these issues further here as 
they would take us too far from the main thrust of the lectures. 

5.5 Generalisations to Non-deterministic Systems 

The fact that the original Goguen Meseguer formulation was restricted to deter- 
ministic systems is a serious limitation. Most systems of interest will manifest 
non-determinism, either because it is deliberately introduced for, say, crypto- 
graphic reasons, or because it arises as a result of abstracting internal details 
of the system. The first person to investigate how the Goguen and Meseguer 
formulation could be extended to deal with non-deterministic systems was Mc- 
Cullough [52,53] . He proposed a generalized version of non-interference but found 
that this, at least with respect to the definition of composition he proposed, failed 
to be compositional. Compositionality is widely regarded as a desirable feature 
of a security property: i.e., given two systems that each satisfy non-interference, 
then some suitable composition of them should also automatically satisfy it. 
Whether it is reasonable to assume that a valid definition of non-interference 
should be compositional is still a matter for debate. We will return to the ques- 
tion of compositionality later. 

Problems of compositionality, non-determinism and the semantics of in- 
puts and outputs have prompted a proliferation of variations on the original 
non-intereference formulation. These include: generalised non-interference [52], 
non-deducibility [88] , non-inference [66] , restrictiveness [53] , forward correctabil- 
ity [39], non-deducibility on strategies [90], trace closure properties [45] and 
McLean’s selective interleavings [59]. We will not go into the details of all of 
these as this would involve presenting a whole raft of models of computation 
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and would take us off the main thrust of these lectures. We will see a little 
later how several of these can be related when viewed in a process algebraic 
framework. 



6 The Process Algebraic Approach 

A central message that we want to convey in these lectures is that process alge- 
bras provide very effective frameworks in which to specify and analyse security 
properties, especially of distributed systems. There are a number of reasons for 
this. Process algebras are specifically designed for reasoning about systems inter- 
acting via the exchange of messages. They deal carefully with issues that we will 
see shortly are crucial to the study of security: non-determinism, composition, 
abstraction and the equivalence of systems. Added to these theoretical consid- 
erations is the fact that over the past decade or so the tool support for process 
algebras has improved dramatically: both theorem-proving and model-checking 
verification tools are now available. 

6.1 Introduction to CSP and Process Algebra 

We will base most of our discussion around the process algebra CSP. However, 
we will find that concepts from other algebras such as CCS and the pi-calculus 
are also useful, [61] and [63]. We start with a simple introduction to those aspects 
of CSP that we require. 

Communicating Sequential Processes (CSP) was originally developed by 
Hoare to reason about concurrent systems interacting via hand-shake commu- 
nications [36]. This was developed further by Roscoe and Brookes [7], and oth- 
ers. Timed CSP was originally proposed by Reed and Roscoe in [70] and fur- 
ther developed by Davies and Schneider [13]. For more up-to-date expositions, 
Roscoe [73] or, with more about Timed CSP, Schneider [82]. 

The interface of a process P is represented by its alphabet, denoted by aP, 
which is a collection of externally visible events (or actions) through which it 
can interact with the environment. Interaction takes the form of synchronisation 
on events. Thus, in order to interact, two processes simultaneously participate 
in some event, a say, and both move together onto the next state. This is an 
abstraction of the notion of a handshake communication and is well suited to 
many situations. Sometimes we really want to represent interaction in a more 
asynchronous fashion in which a process outputs some signal into the ether 
that might or might not be received by some other remote process at some 
later time. Typically this situation can be modelled within the CSP framework 
by introducing a medium with which the processes interact synchronously but 
which may delay or even lose messages, thus mimicking the effect of asynchronous 
communication between the end-points. 
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6.2 CSP Syntax 

The basic syntactic constructs that will be of interest to us are as follows: 
Prefix: 



a 



P 



Prefix choice: 



a : A ^ P{a) 



Communication (input) : 



clx 



P{x) 



External choice: 



pa Q 

Non-deterministic (internal) choice 



PnQ 

Parallel composition over the alphabet A: 



Interleave 



P lU Q 
P III Q 



Hide events from the set A: 



P\A 



Rename: 



P[a/b] 



P after trace tr: 



P/tr 



Let us explain these more fully: 



Prefix The process term a P can initially participate in the action a after 
which it behaves as the term P. 
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Prefix Choice This is similar to prefix except that we provide a set of events A 
from which the choice of prefix event must be drawn. Note that the continuation 
after the event a may be dependent on a. 



Communication It is sometimes convenient to think in value-passing terms in 
which values can be communicated over channels rather than simply synchro- 
nisation on events. Channels will have types assigned to them. Let us denote 
the type of c by T(c). Thus the term clx — > P{x) can accept a value, x : T{c), 
over the channel c after which it behaves as the term P with appropriate inter- 
nal variables bound to the value x. It is thus very similar to prefix choice but 
provides a syntactic sugar. In particular we can have channels with compimd 
types. 



External Choice P U Q represents a choice of the two processes P and Q. 
If the initial events of P and Q are distinct the choice can be made by the 
environment, hence the name. Thus suppose that: 

P --a^ P' 

and 

Q:=b^Q' 

If the environment offers a to P □ Q then a will occur and P O Q will 
thence behave like P' . Similarly if the environment offers b, then b will occur and 
P O Q will subsequently behave like Q'. If the environment offers both a and b 
the choice will be made arbitrarily. Also if the intersection of the alphabets of P 
and Q is non-empty and the environment offers an event in this intersection then 
again the choice of continuation will be arbitrary. 



Internal Choice Like P O Q the term P r\ Q represents a choice between 
P and Q but this time the choice is made internally and the environment has 
no influence over this choice. Consider P and Q above and suppose that the 
environment offers the event a to P □ <5 . It may be that the internal choice goes 
for the right-hand branch, i.e., b ^ Q' and so the event a is refused. As long as 
the environment insists on offering a there will be deadlock. 



Parallel Composition In the alphabetised parallel composition of two pro- 
cesses P ||yi Q, P and Q synchronise on all events from the set A, with A C 
aP n aQ. Thus, for any event from A both P and Q must simultaneously be 
prepared to participate for the event to occur. When such an event does occur 
both P and Q move together to their next states. Any events outside the set A 
can occur quite independently in either P or Q. 
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Interleave In the interleaved composition of P and Q, P ||| Q, both processes 
can make progress entirely independently of the other. There is no synchronisa- 
tion and hence no interaction between them. In fact we have: 

P III Q = P\\{} Q 

i.e., interleave can be thought of as parallel composition over the empty 
alphabet. 

Hiding Hiding over a set C simply removes events from C from view of the 
environment. Such hidden events are internalised: the environment cannot (di- 
rectly) see or influence their occurrence. It is usual to refer to such internal, 
hidden events as r events. 

Renaming Renaming alters the identity of events. In general we can perform 
a renaming with respect to a relation on the events. More typically we will 
rename with respect to a one-to-one function. Sometimes also we will find it 
useful to rename several distinct names to a single name. We will refer to this 
last as projection. 

Renaming is useful when writing CSP specifications as an alternative to 
parametrised specifications where, for example, the specification involves repli- 
cated components. In the context of security we will see that it is a rather useful 
abstraction operator that allows us to neatly capture a number of requirements. 

After P/tr, where P is a process term and tr a trace, denotes the process P 
after it has performed the trace tr. For a non-deterministic system, P /tr will 
correspond to a set of states reachable by the trace tr. We will explain this more 
fully when we introduce the notion of a Labelled Transition System (LTS). 

Constructs also exist for (mutual) recursive definitions of processes but these 
will not concern us. 

6.3 Semantics 

The semantics of CSP processes is traditionally presented in a denotational style, 
that is, a denotational space is constructed along with a mapping from the lan- 
guage to this space. In fact a number of denotation spaces, or models, have been 
constructed for CSP and which is appropriate for a given application depends on 
the kinds of property of interest and the kinds of distinctions between processes 
that are relevant. The simplest model is the traces model. A trace is simply 
a sequence of (visible) events representing a possible behaviour. In this model 
a process is mapped into the set of traces that correspond to its possible be- 
haviours. Such a trace set must always contain the empty trace: for any process 
not having done anything must be a possible behaviour. Furthermore such a set 
must be prefix closed: if a certain behaviour is possible for a process S then any 
behaviour leading to that behaviour must also be possible: 
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0 € traces{S) 



and 



s ^ t G traces{S) s € traces{S) 

Consider a simple example: 

P ■- STOP 

Where STOP is the process that does nothing (so traces(STOP) = {()}). 
The traces of P are: 



{{),{a){a,b),{a,b,c)} 

We can calculate the traces set for a process term P, denoted traces (P), by 
structural induction on the syntax. Details can be found in [73] or [82]. Trace sets 
are thus much like the acceptance languages associated with finite automata. 
The traces model is well suited to reasoning about safety properties, that is, 
where we want to specify and check that certain undesirable behaviours are not 
possible. For deterministic processes the traces model is sufficiently rich to fully 
characterise processes. A process P is said to be deterministic if, for any possible 
trace, the set of events it is next prepared to participate in is well defined. Thus 
there is no trace tr after which in one run event a is offered by S whilst in 
another run which is identical as far as the visible trace tr is concerned, a is 
refused by S. Branching can occur, but it is controlled by the environment. 

Where we are concerned with non-deterministic behaviour the trace model 
is not rich enough, indeed it is not rich enough to characterize when a system 
is deterministic. A simple example illustrates this. Consider the two processes 
P and Q (different to those earlier) defined by: 

p = a^{b^ STOP □ c ^ STOP) 

Q = a^{b^ STOP n c ^ STOP) 

These have the same trace sets: 

{(), (a), (a, b), {a, c)} 

But a system trying to interact with them will typically be able to distinguish 
between them: in particular Q \ \c STOP could deadlock after a (if Q internally 
decides on the right-hand branch of the choice), whilst P ||c STOP can’t, it must 
continue to offer b. Thus, although the space of potential behaviours is identical 
a user’s experience of interacting with these two processes could be completely 
different. If the user is set on Q doing b, say, but Q has chosen the RHS of the 
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n and so is only prepared to offer c, then the user will probably end up kicking 
Q in frustration. This could not happen with P. 

To reason about, and indeed distinguish, non-deterministic behaviours and 
liveness we need a richer model: we need to look at what a process may choose 
to refuse (or conversely, accept) as its behaviours unfold. To achieve this we now 
introduce the notion of a refusal set. 

Suppose that the environment E initially offers the process P a set of 
events X, ii P || E can deadlock immediately then X is said to be a refusal 
of P. Thus {«} is a refusal of a — > STOP FI & ^ STOP. So is {6} but {a, 6} 
isn’t. Note that if A is a refusal for P then any subset of X will also be a refusal. 
The set of such refusal sets is denoted by refusals(P). 

This gives us information about what P may choose to refuse at the outset. 
We now extend this idea to give us refusal information as the behaviours of 
P unfold by introducing the failures of P . 

A failure is a trace along with a refusal set. Thus: 



failures(P) = {{tr,X) 


tr G traces{P) A X G refusals {P / tr)} 


Consider a simple example: 






P = a- 


STOP □ b - 


STOP 


Q = a - 


STOP n b - 


STOP 



Thus 



failures{P) = {((), {}), ((a), {a, b}), ((6), {a, &})} 

Whilst: 

failures{Q) = {((),{a}), ((),{&}), ((a), {a, 6}),((&),{a, &})} 

And so we see that the failures sets for P and Q are distinct in the failures 
model. Here for brevity we have just given the maximal refusals. The sets should 
be filled out with the subset closures of the refusal sets. We find that the failures 
of Q include the elements: 



(0,{a})and((),{&}) 

These are absent in the failures of P. This precisely reflects the fact that 
Q could, at the outset, decide to refuse a or to refuse b. P by contrast cannot 
refuse either. 

Given the failures model we can state formally what it means for a process 
to be deterministic: 
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Definition S is deterministic iff: 

Vs G traces{S) A a G aS^ (s ^ a G traces{S) A (s, {a}) G failures(S)) 

In other words, we should not be able to find a trace after which some event 
might, in one run, be accepted, whilst in another, be refused by S, i.e., a be- 
haviour after which the process can internally choose either to accept or refuse a. 

An important point to note is that refusals, and hence failures, are defined 
on stable states. Stable states are ones in which no internal progress is possible. 
A stable state is one from which there are no outgoing r transitions. The reason 
for this is that it is difficult to meaningfully assign refusals to unstable states 
as any internal transitions (invisible to the environment) may change these. 
Refusals are thought of as sets of events that, if offered to the process will never 
be accepted, at least before any external process has occurred. For unstable 
states such a definition is inappropriate. 

Non-determinism can arise in three ways: explicitly from the internal choice 
operator, from hiding, or from ambiguous external events, e.g.: 

(a ^ ^ STOP □ a ^ c ^ STOP) 

Other semantic models exist, for example, the failures/divergence model de- 
signed to reason about internal thrashing, i.e., situations in which infinite se- 
quences of internal events are possible without any external progress taking 
place. We will not need these for what follows. 



Refinement Refinement, denoted C with a subscript to indicate in which model 
it is defined, is defined as set containment in the appropriate denotational model. 

In the traces model: 

P Cy (5 => traces{Q) C traces (P) 

In the failures model: 

P Ef Q failures(Q) C failures(P) 

Refinement can be thought of as making processes more predictable. In the 
traces model we are simply asserting that a refinement cannot introduce new 
behaviours. In the failures model we are asserting this but also asserting that 
the refined process will never refuse events that were not refusable by the spec- 
ification. This allows us to make assertions about the liveness or availability of 
the system to the environment (e.g., the users of the system). In particular, re- 
finement should not introduce new ways for the system to deadlock. Refinement 
is monotonic with respect to the CSP operators, e.g.: 

p Qt p' A Q Q' ^ p \\ Q p' \\ Q' 



P p' ^ P\c Qt p' \c 



24 



Peter Y. A. Ryan 



Some Useful Processes A few useful processes that we will need include: 
STOP, that refuses to do anything: 

traces{STOP) = {()} 

RUN A, always prepared to do any event drawn from A. Thus: 

RUNa = x£ RUNa 

and 



traces{RUN a) = A* 

Where A* is the set of all finite sequences with elements drawn from A. 

The process CHAOS a may at any time choose to accept or reject any event 
from A. Thus: 

CHAOSa = STOP n{{x gA^ CHAOSa) 

and 

failures{CHAOSA) = {{U,X) \ tr G A* /\ X C A} 



6.4 Labelled Transition Systems 

In what follows it will often be useful to think in terms of an underlying labelled 
transition system (LTS). This is somewhat alien to the usual spirit of CSP, 
which is to concentrate on the external observations that can be performed on 
the system and abstract from all internal details. However, in the context of 
security, these internal details will often include the high-level user and so we 
have to be careful how we treat them. In particular we can’t simply abstract 
them away. 

In an LTS representation a process is thought of a collection of nodes, some 
of which are linked by labelled, directed arcs. A pair of nodes that are linked by 
a directed arc with label /r will represent the possibility of a transition between 
them associated with the event ^ in the direction of the arc, where ^ can be an 
internal r event. 

In general, a process term will correspond to a set of nodes of the underlying 
LTS. For example, P/tr will in general correspond to a set of (stable) states 
reachable by P executing the visible trace tr. 

6.5 Acceptances and Ready Sets 

The standard way to capture non-determinism in CSP is to use refusals. At first 
glance this may seem a little counter-intuitive and begs the question: why not 
think in terms of what the process will accept rather than what it will refuse? 
There are good technical reasons to use refusals for CSP rather than acceptances 




Fig. 1. Refusals vs ReadySets 



as explained in [73]. For our purposes it is more intuitive to think in terms of 
what the system will accept. In particular this sits more comfortably with the 
bi-simulation approach to defining process equivalence that we will see shortly. 

Acceptance sets are defined in a fashion dual to the defintion of refusal sets: 
X is an acceptance set of P if, when the environment offers the set X to P, an 
event in X will be accepted. Acceptance sets are defined to be superset closed, 
where closure is taken with respect to the universal alphabet X. The idea is 
that if an element of a set A will be accepted then if a larger set is offered then 
something from this larger set should again be accepted. 

We will also need to define the idea of a ready set. This is defined in terms 
of the underlying LTS. Each node of the LTS has associated with it a ready set: 
the set of events that the system offers to the environment when in this state. 
It is thus the set of labels on the outgoing arcs from the node. 

The distinction between acceptances and ready sets is that in the case of 
ready sets we do not take superset closure. Ready sets allow us to draw finer dis- 
tinctions between processes than is possible with either acceptances or refusals. 
The subset or superset closure associated with the acceptances wipes out certain 
distinctions that are preserved when working purely with the ready sets. Figure 1 
serves to illustrate this: the refusals of P and Q are identical, i.e., {{a}, {&}, {}}, 
whilst the ready sets of P are {{a}, {&}} and for Q they are {{a}, {6}}, {a, b}}. 

In the context of security the ready sets model seems the most appropriate. 
It is slightly more discriminating than either the failures or acceptances, i.e., it 
draws finer distinctions between processes and so allows hostile agents to draw 
more inferences about the state of the system. Thus, from a security point of 
view, it is a safer model to work with. 

Usually refusals, acceptances and ready sets are defined only over stable 
states. This corresponds to assuming that internal events occur eagerly as soon 
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as they are available. However for our purposes we will not want to treat all 
internal events as eager as we will want to think of some of them as under the 
control of the High user. Consequently we regard ready sets as being defined on 
unstable states as well as stable. In some contexts we want to include r’s in the 
ready sets. 

Where we need to consider a process term corresponding to sets of nodes of 
the LTS we need to consider the corresponding sets of ready sets. Let Nodes (P) 
denote the set of nodes, both stable and unstable, corresponding to the term P. 
Then 



ReadySets(P) = {Ready (p) \ p G Nodes (P)} 

Often we will want to restrict the ready sets to some subset of the alphabet 
and we use a subscript to indicate this. Thus Readyi denotes the acceptance set 
restricted to L. Ready lt will denote the ready set restricted to LU {r}. 

One final piece of notation we will need is that of initials. The initials of 
a process term P are the events P might be prepared to participate in next, 
ignoring non-determinism: 

initials{P) = {a \ (a) G traces{P)} 

We have now set up all the necessary machinery to introduce various process 
algebraic definitions of non-interference. 

7 CSP Formulations of Non-interference 

We now present a formulation of non-interference in CSP, originally presented 
in [75], that stays close to the spirit of the original Goguen-Meseguer formula- 
tion but takes account of non-determinism and dispenses with any distinction 
between inputs and outputs. 



y tr G traces{S) • ReadySetsL{S / tr) = Ready S ets l{S /{ tr f L)) (4) 

tr I" L projects the trace tr down onto the event set L. It thus has much the 
same effect as purgeniitr) except that here we do not draw any input/output 
distinction and so we in effect “purge” all high events. The ready sets projected 
onto Low’s alphabet encode the non-determinism visible to Low. This formu- 
lation therefore seems to be the natural way to extend the Goguen-Meseguer 
formulation into a CSP framework in a way that accounts for non-determinism. 

The same reference also gives a more symmetric formulation: 



V tr, tr' G traces{S) »tr « tr' => ReadySetsh{S / tr) = Ready S ets l{S / tr')) (5) 
Where 



tr K. tr' ^ tr \ L = tr' [ L 
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These are closely related but differ in some subtle ways that we will discuss 
shortly. Where the system S is known to be deterministic we can get away with 
just using initials in place of ReadySets. 

Both of these look a little inelegant as they involve quantification over traces 
and we would like to give an algebraic formulation. An obvious formulation to 
try is: 



S\H =ReadySets{S \\h STOPh)\H ( 6 ) 

The idea here is that composing S in parallel with STOP over the H alphabet 
has the effect of preventing the occurrence of any H events in the RHS of the 
equality. The RHS thus represents the system with all H events prevented. On 
the LHS of the equality S’s interactions with H can proceed unhindered. At first 
glance this seems as though it should give us what we want: that the original 
system from Low’s point of view is indistinguishable from the system with no 
High activity. 

It actually turns out to be a weaker property for rather subtle reasons to do 
with the standard semantics of CSP. As remarked earlier, the standard failures 
semantics of CSP only applies to stable states, i.e., states from which no r tran- 
sitions are possible. The H’s have been hidden and so are abstracted eagerly and 
so Equation 6 only constrains the ready sets on stable states. The quantification 
over all traces in Equation 4, on the other hand, ensures that this definition also 
constrains states from which High can perform an action. Clearly the latter is 
appropriate: such H actions could potentially influence the events available to 
Low. 

One way to rectify this, proposed by Roscoe [72], is by using the CHAO Sr 
process in place of STOPr- 



S \ H = ReadySets (5 ||ff CHAOSr) \ H (7) 

CHAOS R can choose to deadlock on an event from H at any time, including 
at any state from which S would accept an H event, and so this formulation, in 
effect, gives quantification over all traces. 

Alternatively we can give a formulation that mirrors the symmetric formu- 
lation of Equation 5 with: 



y U,U' e PrOCeSSR •{S jjff U) = ReadySets {S jjff U') (8) 

This is actually a very intuitively appealing formulation as it is really saying 
that Low has no way to distinguish between users who are interacting with the 
system through the high-level interface. 

These formulations raise a number of points that deserve further discussion. 
Firstly, CSP draws no distinction between inputs and outputs. We deal simply 
with events. The act of interaction between processes is thought of as a symmet- 
ric, co-operative activity. Both processes must agree to participate in an event 
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for it to occur. If either refuses the event then it will not occur. As soon as 
both agree, it can occur. There is no concept of one of the processes causing or 
controlling the occurrence of an event. We will discuss later some elaborations 
of the usual CSP framework to allow us to draw causal distinctions if and when 
appropriate. 

Not drawing any input/output distinctions is a safe option: we won’t make 
errors as a result of incorrectly categorising events. On the other hand, it may 
be overly strong in some cases and we may find ourselves rejecting systems that 
would seem to be secure. 

A related point is that the formulations of Equations 4 and 7 imply that the 
purge of any trace is itself a valid trace. At first glance this would seem right: 
we are, in effect, saying that to Low the system always looks as though High 
has done nothing. However, we have to be careful. Consider a system in which 
an activity of Low triggers an alert message on High’s screen and let us suppose 
that High cannot prevent or delay this message. Here Low will know when such 
an alert event will occur at the High level (because he caused it) but we would 
not usually regard this as representing a flow from High to Low. The point is 
that the occurrence of the alert event cannot be influenced by High and therefore 
cannot be used by him to signal to Low. 

To illustrate this further consider the simple process: 

S=l^h^h^ STOP 

Low can deduce that h has occurred when he sees I 2 ■ The purge formulation 
would reject S as insecure. If /i is a signal event (e.g., an alarm) over which High 
has no control we really should regard this process as secure. 

If h is not refusable or delayable by High, i.e.. High can only passively observe 
its occurrence, then, for the purge formulation, we should use the process S': 

S' = l^{{h^k^ STOP) □ {h STOP)) 

H refusing h does not deadlock S. Or, equivalently, we could use the origi- 
nal S with the symmetric formulation. Of course, if the occurrence of h can be 
influenced by High then we would be right to regard S as insecure. Thus, by 
suitable formulation of our models, we can capture distinctions between signal 
and refusable events. We will discuss later how, using the framework of testing 
equivalence, we can do this in a more systematic and general way. 

Another difhculty with the formulations above is that they suffer from what is 
sometimes referred to as the refinement paradox. That is, we can define a process 
that satisfies them but for which a conventional refinement is insecure. Consider 
the process defined by: 

S = {hi^ {h STOP STOP)) □ (/i2 ^ {h STOP STOP)) 

S satisfies our definitions of non-interference but is refined by: 
S={hi^h^ STOP) □ (/i2 STOP) 
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This clearly leaks information. We will discuss this problem in more detail 
later. It is not unique to the formulations given above. The refinement problem 
was noted long ago by McLean [59] and, in a different setting, by Jacob [37]. 
Intuitively the problem arises from the fact that conventional refinements re- 
duce non-determinism, i.e., make the system more predictable. This is entirely 
appropriate for safety-critical systems but can be disastrous for information secu- 
rity: making a system more predictable potentially allows hostile agents to make 
more precise inferences on the basis of limited information. A stream cipher 
with predictable output is not one in which we should have much confidence, to 
paraphrase Tom Stoppard in “Arcadia.” 

We should also comment on our use of ready sets rather than refusal sets. 
By using ready sets we are again making a worst-case assumption: that Low 
may be able to directly observe exactly which events are on offer. Whether this 
is appropriate really depends on the system in question. If, for example, the 
system has a display of lights that indicate at each point which events it will 
accept then the ready sets formulation is appropriate. 

For other systems it may be appropriate to think in terms of Low performing 
experiments by offering an event or set of events to the system and seeing if 
anything is accepted. If it is accepted then the system moves on to the next 
state and, having moved on. Low can obtain no further information about what 
other events might have been accepted in the previous state. Thus typically the 
information available to Low is much less in this model, hence his inability to 
make such fine distinctions between processes. The subset closure of the refusal 
sets (or alternatively the superset closure of the acceptance sets) encodes this: 
certain distinctions that could be made working only with ready sets are masked 
by the closure. There is a sort of Heisenberg uncertainty principle at play here: 
observing certain parameters of the system tends to disturb it and so disrupt 
the observation of other parameters. 

On the other hand, if the environment can back-track to the initial state after 
an event has been accepted and continue testing then it will be able to identify 
the exact ready set for that state. 

8 Abstraction 

Process algebras provide elegant ways of abstracting away details and encoding 
different views of a system. The most obvious way of abstracting is to hide a set 
of events, C say: 



P \ C 

However, as previously remarked, the standard CSP semantics assumes that 
hidden, internal events occur eagerly. As a result this form of abstraction works 
fine for signal events, e.g., messages to the screen. In some situations, notably 
security, we want to abstract certain events but not force them to be eager, 
they may be under the control of High and so refusable or delayable. Here it is 
appropriate to use lazy abstraction: 
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Lazyc(S) := {S ||c CHAOSc) \ C 

Another, closely related, way to abstract events but without hiding them is 
to camouflage them: 



CmflgciS) := {S ||| RUNc) 

Here the environment can still see the events from C but cannot tell if they 
are associated with S or are just spurious C events from RUNc- 

Variants of these are possible, reflecting certain subtleties of the semantics 
of CSP. A full discussion can be found in chapter 12 of [73]. 

Renaming can also be a useful abstraction operator. We can use it in two 
principal ways: permuting a set of event names or renaming a set of events to 
a single name. We can think of the latter as a sort of projection: Low knows an 
event from the set in question has occurred but not which. 

There are two main ways of using the permutation of a set of events: applying 
the same permutation throughout an execution or using a fresh permutation 
at each step of the execution. The latter really gives the same effect as the 
projection. The former is potentially more interesting as it allows for Low to 
correlate events. We will see later how these are useful for coding anonymity 
and encrypted channels. 

Mixes of these are also possible and, using certain coding tricks, it is, to 
some extent at least, possible in CSP to allow for the abstractions to vary dy- 
namically. This kind of modelling works rather better in a process algebra like 
Milner’s 7r-calculus, which is specifically designed to handle dynamic networks 
of processes. 

9 Unwinding the CSP Formulation 

The formulations above all involved quantifications over traces or processes. We 
would prefer a more convenient definition for verification. In [27] the idea of un- 
winding is introduced. The idea is to replace the original definitions by conditions 
on individual transitions. Assuming that the class of possible transitions is essen- 
tially finite this should give a more tractable formulation set to check. [75] gives 
such conditions for the formulation of Equations 4 and 5. Let us consider the 
latter, more symmetric version, as it will prove more suitable for what follows. 



Unwinding (Symmetric Version) 

— Rule 1: 

V Yi, Yj € States (S) • « Yj => Ready SetsL^Yi) = Ready SetsL^Yj) 
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— Rule 2: 

V Yi, Yj G States(S) • Yi ^ Yj ^ V e € Initials (Yi) , 3tr G traces{ Yj) • 

e ( L = tr f L A Yij e ~ Yj/tr 

Note that we have introduced an (abstract) state space and an equivalence 
relation « on it. Rule 1 has the effect of ensuring that equivalent states give rise 
to the same ready sets when restricted to Low’s interface. Rule 2 ensures that » is 
exactly that induced by the purge of H events. That is, states reached by traces 
with the same purge are regarded as equivalent. A straightforward induction 
argument on the length of traces establishes this correspondence. With this we 
can readily proof that: 



Rulel A Rule2 => NIcsp 

The implication in the other direction is more delicate however, i.e., to show 
that the rules are necessary as well as sufficient. [75] gives a rather clumsy proof 
of this by arguing that any process that satisfies the non-interference property 
can be implemented as a machine that satisfies the rules. 

In fact a far more elegant and insightful proof is possible when one observes 
that the unwinding rules actually bear a striking resemblance to the notion 
of bi-simulation, allowing us to borrow some results from the process algebra 
literature. First we need to introduce a few ideas from the operation style of 
process semantics. 

10 Operational Semantics 

An operational semantics is typically presented in the form of transition rules. 

Thus P P' indicates that the process term P can make a transition labelled 
/j, to the process term P' . The semantics can then be presented in terms of tran- 
sition rules corresponding to the various syntactic operators. Simple examples, 
with empty antecedents include: 



(a ^ P) P 
or 

(a -> P □ 6 ^ Q) P 

and 

(a^Pab^Q)^Q 

The first simply asserts that a process term a ^ P can first perform the 
action a and then behaves like the process P. The latter two simply assert that 
the term a P O b Q can perform an a in which case it subsequently 
behaves as P or a 6 in which case it then behaves as Q. 
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Notice that there are two different kinds of arrows here: inside the brackets 
the arrows are CSP prefix arrows. The longer, labelled arrows denote labelled 
transitions between process terms and are not part of the CSP notation but are 
part of the notation needed to present the operational semantics. 

10.1 Strong Bi-simulation 

Given a denotational semantics, equivalence is simply that induced by the map- 
ping into the denotational space: two processes are deemed equal if they map 
to the same object in the space. In an operational style of semantics this device 
is not available to us and we need alternative ways to characterise the equality 
of terms of the algebra. The semantics is given purely in terms of what actions 
a process term can perform, hence we need to define equality in these terms. The 
usual approach is to use the notion of bi-simulation; intuitively that two terms 
are equal if each is able to match the others actions. 

More formally: processes P and Q are strongly bi-similar if 3 a symmetric 
relation R on the space of process terms such that: 

PRQ A P ^ P' ^3Q' • {Q ^ Q' A P'RQ') 

Here ^ is any transition label drawn from the set of actions of P, including 
t’s. 

In other words, assuming that they start off in equivalent states, if one can 
perform an action /i then the other must also be able to perform the ^ action 
and, furthermore, after these actions they can end up in equivalent states. The 
latter clause ensures that we can unfold this condition to ensure that they can 
continue to simulate each other indefinitely. Thus each can mimic the other. 
Notice that they will not necessarily end up in equivalent states. The condition 
only requires that it is possible for them to reach equivalent states. Thus in 
general there may be other transitions from Q also labelled p, but that end up 
in states that are not related to P' . 

10.2 Weak Bi-simulation 

Strong bi-simulation insists that the processes stay in step on all actions includ- 
ing the hidden r actions. Given that the r actions are not observable by the 
environment this tends to be too strong a criterion. We can have processes that 
are observationally indistinguishable and yet are not strongly bi-similar. Strong 
bi-similarity is thus drawing distinctions dependent on internal, unobservable 
differences between implementations. This is not really in the spirit of the ab- 
stract, implementation-independent, viewpoint of process algebra. The natural 
weakening of this condition is to relax the requirement that the processes stay 
in step on the r’s. 

Weak bi-simlarity is defined in a similar way except that for visible events 
we allow for arbitrary interleavings of r events with the matching event to reach 
equivalent states. A tau transition in one process can be matched by an arbitrary 
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sequence of tau’s, possibly of length zero. Where ^ is a visible event we take 

P P' to indicate that P can transition to P' with a visible event /j, interleaved 
with arbitrary r’s, that is, an element of /i € r*. ^ .r*, or where ^ is a tau event 
f is taken to denote a sequence r” of tau’s, where n could equal 0. We can now 
define the weak-bisimulation relation on process terms. 

Two process terms P and Q are weakly bi-similar if 3 a symmetric relation 
R such that: 



PRQ AP-^P'^3Q'»Q=^Q'a P'RQ' 

Thus, if one process performs a visible event, we require that the other process 
be able to match this but allow for interleaving with t events to reach equivalent 
states. If one process performs a hidden r event, we require that the other be 
able to perform some sequence of r’s, possibly none, to arrive at an equivalent 
state. 

10.3 Unwinding and Bi-simulation 

There is a clear similarity between unwinding rules and (weak) bi-simulation. 
Both introduce an equivalence on states and both require the possibility that 
matching transitions from equivalent states lead to equivalent states. 

The point about this analogy is that it potentially gives us a way of viewing 
unwinding results in a process algebraic context. If we can frame the unwinding 
rules in a bi-simulation style it also potentially gives us a more elegant and in- 
sightful proof of completeness. Furthermore it could give us access to established 
results and algorithms for establishing bi-simulation relations and for verifying 
equivalences of processes. 

There are, however, some differences: bi-simulation does not have an immedi- 
ate analogy of rule 1 of the unwinding conditions, i.e., the matching of the ready 
sets of equivalent states. In fact we will see how this follows from the requirement 
for a bi-simulation that the processes be able to match visible transitions. 

Another difference is that the unwinding rules work with ready sets. It is 
well known that weak bi-similarity is stronger than failures equivalence and, as 
discussed earlier, ready sets equivalence is stronger than failures. 

Bi-simulation differs from failures equivalence in that it makes distinctions ac- 
cording to where non-determinism is resolved, i.e., at what point internal choices 
are made. Consider the following simple example that illustrates this: 

p = (a^ STOP) □ (a ^ c ^ STOP) 

Q = a^{b^ STOP n c ^ STOP) 

In the first the branching occurs before the visible a event whilst in the 
second it occurs after the a. They can easily be shown to be failures and test- 
ing equivalent. These two processes are actually also ready sets equivalent as it 
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happens. Any process interacting with them but with no visibility of the inter- 
nal mechanisms would be unable to distinguish them. It can easily be shown, 
however, that no bi-simulation relation between them can be constructed. 

At this point we could adopt the position that because bi-simulation gives 
a stronger and therefore, arguably, a safer definition of secrecy and we could 
simply adopt a bi-simulation definition of security. This would give a formulation 
of secrecy along the lines of those proposed by Gorrieri et al, [19] and described 
in the chapter by R.Focardi, R. Gorrieri of this volume. 

In fact bi-simulation-style definitions of process equivalences have been for- 
mulated that are precisely equivalent to the failures equivalence, and indeed 
which, with a minor change, can also capture ready sets equivalence. We can 
therefore utilise these to produce a bi-simulation-style formulation that is ex- 
actly equivalent to our unwinding rules. 

In the theory of automata it has long been known that a non-deterministic 
finite state automaton can be converted into one that is deterministic and equiv- 
alent with respect to the acceptance language model. The construction involves 
lifting the model to the power set of the state space and working with sets of 
nodes and transitions rather than single nodes. This is not quite what we want 
as the accepting language model ignores non-determinism. It does, however, give 
an indication of how to proceed. 

Gardiner introduces a formulation of simulation that is equivalent to failures 
refinement of GSP [24]. In a more recent paper this is extended to provide a con- 
struction of bi-simulation that corresponds to failures equivalence and indeed, 
by a slight tweak of the construction, also provides a construction that corre- 
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spends to the ready sets equivalence [25]. The details are quite elaborate and 
beyond the scope of these lectures. We will try to give the intuition and provide 
a construction for processes that satisfy our definitions of non-interference. 

10.4 Power Bi-simulation 

The problem with the example earlier was the insistence on relating individual 
states. If instead we think in terms of sets of states we can abstract away from 
the details of where exactly internal choices are made. The key idea then is to 
construct a bi-simulation relation on the power set of the state space: F States. 

For a process S, set of states 4> and visible event a define the spray of (p, 
{[4‘])a, by: 



([<A])a = {P' C States{4>) I 3 a G t* .a.r* • (j) P'} (9) 

That is, ([<^])a gives all states reachable starting from a state in (j> with a 
visible a, possibly interleaved with r’s. 

A relation w on P(6') x P(6') is a power bi-simulation relation for an LTS 
of S if: 



« 52 ^ ([5i]), « {[S2])a (10) 

This in itself is not so useful: trivial solutions for w exist. In particular the top 
relation that relates everything to everything satisfies this so the usual device of 
taking the largest relation satisfying the property is singularly uninteresting in 
this case. To get interesting solutions we need to impose additional constraints 
on « . 

The intuition behind Gardiner’s construction is to find the largest symmetric 
equivalence relation « satisfying 10 and such that for any pair of related elements 
(sets of states) 4>, p' and any subset s £ cp we can find a subset s' of p' such 
that: 



initials{s) C initials{s') 

Thus, refering to figure 2 again, the node Q' must be matched up with the 
pair of nodes {P[, P^}: whilst P[ can be matched with just Q'. 

This gives a characterisation of equivalence that is exactly as discriminating 
as failures equivalence. Alternatively we can obtain ready sets equivalence using 
the slightly stronger requirement of = of initials rather than C. It also turns 
out that for the ready sets model the bound has to act on stable states rather 
than arbitrary states as was the case for the failures equivalence. Gardiner shows 
that such constructions give bi-simulation characterisations of equivalence that 
correspond exactly to traces, failures or ready sets (depending on the choice of 
bound) . 
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The construction is related to the normalisation performed by FDR, the 
model-checker for CSP. FDR stands for Failures, Divergences and Refinement. 
The tool, marketed by Formal Systems Europe Ltd performs refinement check 
between pairs of CSP specifications [17]. The tool creats an LTS representation 
of a CSP specification. During normalisation it converts the original LTS to 
a Generalised LTS (GLTS), whose nodes correspond to sets of nodes of the 
original with annotations (minimal acceptances) to carry the non-determinism 
information. 

10.5 Loose Bi-simulation 

We now introduce a construction for the power bi-simulation relation for systems 
satisfying the definitions of non-interference given by Equation 5, or equivalently 
Equation 8. 

Once again it is helpful to think in terms of an underlying Labelled State 
Transition System (LTS) with internal transitions exposed, i.e., with labels 
drawn from H U LU {r}. 

Define the relation on states of S by: 

= {{S / tr , S / tr) I tr,tr' G traces{S) f\ tr \ Lt = tr' f Lr} (11) 
where Lt- = T U {r} 

In effect this is the equivalence relation induced by purging the H's but 
keeping the L’s and r’s visible. 

We now define a variant of weak bi-simulation that we call loose bi-simulation: 
P and Q are loosely bi-similar if 3 a symmetric relation such that: 



P Q A P ^ P' ^ 3 Q' . Q Q' A P' 0' (12) 

Where, for ^ S L U {r}, /i denotes a sequence of events in H*.p,.H*, the 
set of all finite sequences of H actions interleaved with a single p,. For p G H 
we take p to denote a sequence of H events, possibly of length zero. It is thus 
analogous to weak bi-simulation but with t and L events kept visible whilst the 
H's are hidden. Thus the H's playing the role of r’s. 

10.6 Power Bi-simulation for Non-interference 

We now define a power bi-simulation relation on F States{S) x F States (S) : 



~S'= {({-S' I S S'}, {5 I S S'}) I tr, tr' G traces{S) 

/\ tr \ L = tr' \ L} (13) 

i.e., abstracting the r’s and H's. Note that this relation acts on the power 
set of the state space and so relates sets of states to sets of states. 
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Lemma 1 . If S satisfies the loose bi- simulation w.r.t. then it satisfies 
a power bi-simulation w.r.t. 

The proof follows straightforwardly from the definitions. 

Lemma 2 . If S\ wg S2 then for all si € S\ there exists S2 G S2 such that 
Si S2, and vice versa. 

Again the proof is a straightforward, if slightly messy, induction argument. 

Lemma 3 . 



Si S2 ^ ReadyL{si) = ReadyL{s2) 

This follows immediately from the definition of loose bi-simulation: states 
related by must be able to match transitions and so they must match ready 
sets. 

Lemmata 2 and 3 together immediately imply: 

Lemma 4 . 



Si S2 => ReadySetsL{Si) = ReadySetsL{S2) 

Figure 3 may help illustrate what is going on. Here pi and p2 are related by ~ 
and so have matching ready sets on LU { t }. pi is an element of the set of nodes 
I/i and p2 is an element of 1/2 with I/i « 1F2 . The diagram shows both pi and p2 
making transitions labelled mu to p[ and p'2 respectively and, if the system 
satisfies loose bi-simulation with respect to we have p[ ~ P2- Furthermore 
p[ and P2 will be elements of and 1^2 respectively, where = ([^i]);^ and 
^2 = ([^2])/i, with « 5^2. Finally note that ReadyLr{p[) = ReadyLrip^)- 

We have thus established that S satisfies loose bi-simulation w.r.t. im- 
plies S satisfies power bi-simulation w.r.t. and the ready sets bound which 
in turn is equivalent to S satisfying the non-interference property of Equation 5. 

In fact we see that Lemma 4 is really just a restatement of unwinding rule 1 
and Lemma 1 is a restatement of rule 2. 

We have thus constructed a power bi-simulation formulation equivalent to 
the original non-interference property. Completeness, i.e., that this formulation 
is both necessary and sufficient, now follows from Gardiner’s results that show 
that the largest equivalence over the LTS of the CSP language that satisfies the 
equality of initials bound on stable states gives the same equality of terms as 
the ready sets model. 

It is worth examining this construction more carefully. Although originally 
designed as a rather formal exercise in recasting certain results in a process 
algebraic framework and to give a more elegant and insightful proof of the com- 
pleteness of an unwinding result, it actually has some useful spin-offs. Firstly 
notice that we have, in effect, divided the hidden events into H's and r’s and 
are thinking of these as the potential source of any non-determinism that may 
be observable by Low. 
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Examining the loose bi-simulation property we see that it is asserting that 
the occurrence of H' s cannot influence the availability of r’s. We can think of 
the r’s as representing internal, system sources of entropy giving rise to the 
non-determinism visible to L, for example, due to a scheduler or to the output 
of a stream cipher. For a system satisfying non-interference in this framework 
the r’s are the sole source of any non-determinism visible to Low. Different 
T behaviours can resolve the non-determinism in different ways but differing 
H behaviours cannot. The fact that H's do not interfere with the r’s ensures 
that there cannot be an indirect channel from High to Low. 

It may be appropriate to disambiguate the r’s. Usually, in CCS for exam- 
ple, r’s are invisible and so can reasonably be regarded as indistinguishable. 
In our construction above, however, we have, at some stages of the analysis at 
least, exposed the r’s. Suitable disambiguation of the r’s could allow a closer 
correspondence to be established between differing r behaviours and differing 
non-deterministic behaviours manifest to Low. In effect the r’s are doing the 
book keeping that ensures that the non-determinism manifest to Low in states 
equivalent under « is consistent. 

A pleasing feature of the power-bi-simulation approach is that it connects the 
denotational, operational and testing formulations of process equivalence, and 
hence of non-interference. In [33] it is argued that bridging different presentations 
of semantics should be a major goal of theoretical computer science. 

Unwinding results can be interpreted as special forms of bi-simulation and 
so existing algorithms for constructing bi-simulations may be useful for estab- 
lishing unwinding rules. Pinsky provides a construction for equivalence classes 
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in a somewhat different, predicate based framework [68]. These results can be 
mapped across to Gardiner’s predicate transformer approach. 

10.7 Composability 

Reasoning about the composability of various formulations of non-interference 
with respect to various forms of composition becomes much easier in a process 
algebraic framework. Furthermore, having a bisimulation formulation appears to 
help significantly. To illustrate we present a proof of composition for processes 
satisfying our loose bisimulation formulation with respect to parallel composi- 
tion. Parallel composition seems to be one of the more interesting operators to 
consider, interleaving tends to be rather trivial for example. Note that for this to 
make sense, we assume that High channels are linked to High channels and Low 
to Low. Without this assumption non-interference would be trivially violated. 

Suppose the S and T both satisfy loose bi-simulation w.r.t induced by 
purgcH- 

Thus 



Si S2 A Si ^ 3 S2=^ A S^ 

Similarly for T. 

Now consider 5 Hi; T where S = H ULU{r}. The E subscript on || will be 
taken as implicit from now on. 
and define on S' || T by: 

Si II Tl S2 II T2 ^ Si S2 A Tl T2 



Lemma 5. 

II Tl S2 II T2 <t^ 3 si,S 2 G traces{S) • Si = S/si A S2 = S / S2 
where: 

purgenisi) = purgeH{s2) 

And similarly for T . 

That is the equivalence is the same as would have been induced by 
purging the traces of the composed process. 

Now we need to show: 

51 II Tl S2 II T2 A Si II Tl ^ S'l II T[ 
implies 3 S 2 1 1 T 2 such that 

52 II T2 ^ S !2 II T' A S'l II T'l S !2 II T' 

Now 

Si II Tl S{ II T[ ^ Si^ S[ATi^ T[ 
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SO by Loose bisimulation of S and T we must have S 2 and T 2 such that: 

52 ^ 5' A T 2 ^ 

SO _ 

S2 II T2 ^ S!2 II T' 

but we also have: 

S[ A T[ 

so indeed: 

s[ II n '-H s'2 II n 

as required. 

The structure of this proof follows largely from the nature of bi-simulation. 
The only tricky part is in showing that the equivalence used in defining loose 
bi-simulation for the composition of the processes is the same as that used 
for the processes separately. In this case we had to show that the equivalence 
defined above is the same as had we defined it directly from the purge of 
traces of the composed process. In other words, the key step is to show that the 
equivalence used in defining the loose bi-simulation lifts through composition 
in the appropriate way. In this case the proof is straightforward but for the 
subtler forms of non-interference we will meet later it may not necessarily be 
so straightforward (or even necessarily true). Schneider discusses a variety of 
compositionality results with respect to a number of styles of composition results 
in the context of a framework based on testing equivalence [84] . 

10.8 The Roscoe- Woodcock- Wulf Approach 

The fact that the formulations of non-interference given above fail to be preserved 
under the usual refinement of CSP, or indeed most other styles of refinement, 
is troubling. Various responses are possible to this: we could conclude that such 
a formulation is flawed. We could conclude that this is just a fact of life and 
security is not a property preserved under refinement. This would be a distinctly 
depressing conclusion as it would deny us the possibility of step-wise development 
and verification. Another is to accept that conventional refinements will not 
preserve security and if we want security to be automatically preserved we will 
need a new formulation of refinement. Yet another response is to conclude that 
maybe it is unreasonable to expect security to be preserved automatically and 
that we have no choice but to do further verification as we move down towards 
the implementation during the design process: i.e., to generate and discharge 
proof obligations at each refinement step. 

We will discuss the latter reactions a little later. First we introduce an alterna- 
tive CSP formulation of non-interference that is preserved under CSP refinement. 
The approach is due to Roscoe, Woodcock and Wulf [71]. 

The key idea here is to assert that a suitable abstraction of the system that 
represents Low’s view be deterministic. In our earlier formulations we sought 
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ways to allow some non-determinism at Low’s level but denying High any way 
to influence the way this is resolved. In the this approach there simply isn’t any 
non-determinism in Low’s viewpoint. Such a system is fully under the control of 
the environment (as far as it’s externally observable behaviour is concerned) and 
so it cannot be the source of any information or entropy. There may be entropy 
being created and sloshing around internally but it never gets to leak outside. 



Definition. A system S satisfies RWW non-interference, denoted iff 

AbstractH{S) is deterministic. 

Where Abstract h denotes an appropriate abstraction of the H events giving 
Low’s view of the system. 

As remarked earlier, non-determinism is never increased by CSP refinement. 
Consequently, any system that is deterministic to start will remain deterministic 
under refinement. Thus any refinement of a system that satisfies the RWW 
property of non-interference will necessarily also satisfy it. A further advantage 
is that it can be automatically checked, indeed FRD has a button for this. 

This makes the approach very attractive. It is stronger than the previous 
formulations we have discussed: any system satisfying NIrww will also satisfy 
all of the formulations given previously. It also side-steps many of the rather 
delicate issues that dog other formulations: in particular, what is the right notion 
of equivalence to use? How can we be sure that there is not some subtle way 
for High to influence non-determinism that is missed by our models. The latter 
problem is another manifestation of the refinement problem. 

For a system whose security can be formulated as NIrww it is clearly sensi- 
ble to use this formulation for the above reasons. The drawback is that it would 
appear that there is a large class of systems of interest for which this formula- 
tion is not appropriate, i.e., for which some residual non-determinism at Low is 
unavoidable. The classic example is the encrypted channel that we will discuss 
in greater detail later. Suppose that we consider a stream cipher (essentially 
a one-time-pad). This is a source of pure entropy and it does leak to the outside. 
However, a well designed cipher box properly incorporated in a secure architec- 
ture should still be secure. In essence the entropy generated by the box cannot 
be influenced or predicted by High. 

Such an example cannot, in any obvious way at least, be formulated in the 
NIrww style. Actually it is not trivial to formulate in other weaker formulations 
either and we will return to this point later. 

Another appealing feature is that the definition of determinism is fairly un- 
controversial and coincides for most process algebras. 

It is possible to combine this approach with the loose bi-simulation approach 
described earlier: consider an abstraction of the system with the H’s abstracted 
but the r’s kept visible and indeed disambiguated. We now require that this 
abstraction be deterministic. This is stronger than the loose bi-simulation that 
we introduced earlier and indeed implies it. The real system again has the t’s 
abstracted and so can manifest non-determinism at Low’s interface. Again we 
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know that any non-determinism visible to Low will be entirely due to differing 
T behaviours and furthermore we know that High’s activity cannot influence 
the r’s. We thus get the best of both worlds: a simple and easily verifiable and 
refinable property that still allows for some non-determinism at Low’s level. 

For this to work we certainly need to disambiguate the r’s as we would 
otherwise have non-determinism due to ambiguous branching on r’s. There seems 
no reason not to do this and indeed the identification of all internal events with 
a single event could itself be regarded as a modelling device, an entirely sensible 
one for hidden events. 

We also need to avoid non-determinism arising from ambiguous Low events. 
In fact we can always transform a system with ambiguous visible events to one 
in which such branching is replaced by r branching. 

10.9 The Jacob Security Ordering 

A drastically different approach to formalising security was taken by Jacob, 
[37,38]. Jacob suggests that there is, in fact, no way of saying categorically 
whether or not a system is secure. In this approach security is considered to be 
a purely relative property: at best all we can do is establish that one system is 
at least as secure as another. To this end he introduces a security ordering based 
on the notion of infer functions. Given a Low level projection of a trace the infer 
function returns the set of system behaviours consistent with this observation. 
Formally: 

Given a trace tr G trace (S) 



The larger the cardinality of the set returned by infer the greater the uncer- 
tainty about the system behaviour associated with that observation. The idea 
now is, for a pair of systems P and Q, to compare the size of the infer function 
for all possible Low observations. We will consider P to be at least as secure 
as Q if: 



In other words, for any given Low observation, the set resulting from the infer 
function applied to P is always a superset of the corresponding infer function 
for Q. Thus the uncertainty resulting from observations of P is always greater 
than would be the case for Q. 

The idea is very interesting, but it has failed to catch on, presumably because 
people have tended to feel uncomfortable with not being able to characterise a 
given system as either secure or insecure. Given that security is never absolute 
this is really not a valid objection. To return to the safe analogy: it is not 
meaningful to rate a safe as “secure,” but it may be meaningful to claim that 
one safe is more secure than another, i.e., for all known forms of attack it will 



infers(tr) := {s | s S traces{S) As \ L = tr \ L} 



(14) 



\f tr G traces{Q) • inferQ(tr) C inferp{tr) 



(15) 
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withstand for a longer period. The time may be ripe to take a fresh look at this 
approach. 

10.10 Testing Equivalence 

Another way of characterising process equivalence is the notion of testing. The 
idea is highly intuitive: if no experiment that the environment can perform on 
a pair of systems P and Q can distinguish between them then they are deemed 
to be equivalent. This is really very compelling in the context of security as 
we can think of these experiments as representing the efforts by Low to infer 
something about High’s activity. 

Schneider shows that several of the existing formulations of non-interference 
style properties can be cast rather naturally as flavours of testing equivalence [84]. 
Indeed it seems that in several cases the authors of these were in effect inde- 
pendently reinventing certain flavours of testing equivalence. We will show, for 
example, how non- deducibility and non- deducibility on strategies emerge nat- 
urally from thinking in terms of testing equivalences. First we give a formal 
definition of testing equivalence. 

A test is a process T with a distinguished success event w. We allow the 
system P to run in parallel with T and observe whether the resulting process can 
reach a state in which the w event is possible. We can then characterise processes 
in terms of the set of tests they pass, which provides us with an alternative way 
to assign meaning to process terms. In particular, we regard two processes that, 
for all possible tests, pass the same set of tests as equivalent. We have to make 
precise what we mean by all possible tests. Typically this will simply be the space 
of tests that can be expressed in the process algebra. In some circumstances we 
may want to constrain the space of possible tests to reflect limitations on the 
capabilities of the environment (or hostile agents in the case of security). 

To formally define the notion of a test we need to introduce a special 
SUCCESS process which satisfies the transition rule: SUCCESS STOP. 
Thus, SUCCESS is a simple process that performs a success event w and then 
stops, w is a special event that is introduced purely as a device to define the 
success of a test and will not be part of the universal alphabet E. 

Success of a test is now characterised by whether the process: 

T)\E 

can perform lo. Where T is constructed from the CSP operators along with 
the SUCCESS process. Thus the occurrence of the cv event signals that P has 
agreed to perform some behaviour offered by T. You can think of T as repre- 
senting some abstract test harness that is attached to P. 

10.11 May Testing Equivalence 

There are three possible outcomes of such a test when applied to a particular 
process: it might always succeed, always fail or sometimes succeed. 



44 



Peter Y. A. Ryan 



If Hi; T) \ S can perform ui then we will say that P may pass T, written 
PmayT. That is, 3 an execution of (P ||i; T) \ S that results in w. It is possible 
that there are executions of P that do not result in w so success is not guaranteed, 
hence the name may testing. 

P and Q are now deemed to be may testing equivalent, written P =may Q, 
iff: 



V T • PmayT QmayT 

In other words the set of tests that P may pass is exactly the same as the set 
that Q may pass. May testing equivalence is known to give the same equivalence 
as the traces model [10]. 

An analogous notion of must testing can be defined by requiring that all 
(maximal) executions of (P jjx’ T) \ H result in an w. This gives an equivalence 
that corresponds to the failures model of CSP. The condition of maximality is 
required because there will always be the possibility of short runs that have not 
reached the success state but would if allowed to continue and so should not be 
regarded as a failure of the test. 

10.12 May Testing Non-interference 

We can use the form of equivalence given by may testing to give another state- 
ment of non-interference. 

Definition: S is mayNI if for all High processes Hi and P 2 , with aHi C H: 



Hi jiff 5 IIl T=may ^2 \\h S \\l T 



(16) 



With aT Q L 

This gives a weaker characterisation than those given above as may testing ig- 
nores distinctions that Low may draw based on observations of non-determinism. 
We can give a formulation similar to, say. Equation 9 by requiring must testing 
equivalence [84]. 

10.13 Non-deducibility 

Equation 17 is the natural thing to write down in a may testing framework. 
However, by altering this slightly, we can mimic one of the early formulations: 
non- deducibility due to Sutherland, [88]. The essential idea is to stipulate that 
whatever observations Low may make of the system the space of possible High 
level inputs consistent with those observations is unchanged. Intuitively this 
is rather appealing and appears to address the encryption problem: whatever 
ciphertext Low observes he cannot reduce the space of plaintexts compatible 
with this ciphertext. 

We need to partition the High level events into inputs and outputs. We then 
restrict the high-level processes in the definition to ones with an alphabet drawn 
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only from High inputs and we use this in the definition of Equation 17. This 
is not really a natural thing to do in a process algebraic framework and indeed 
it and Sutherland’s original formulation are found to be flawed, as observed by 
Johnson and Wittbold [90]. 

Unsurprisingly, the problem arises from ignoring the High outputs. Wittbold 
et al, construct a system that satisfies non-deducibility but for which High can 
modify his behaviour based on observations of High outputs in such a way as 
to signal to Low. The construction amounts to a stream cipher that High can 
induce to stutter. This allows him to predict certain bits and so leak plaintext 
to Low. In fact, as remarked in [77], this is really conceptually this same as High 
somehow being able to observe the bits of a cipher stream before he submits 
his plaintext. If he can somehow achieve this he can now exclusive or these into 
the High inputs (plaintext) . The self inverse property of Vernan encryption then 
results in raw plaintext being visible to Low. 

It might seem unlikely that such a flawed installation of a cipher device would 
be implemented in a secure system but the point is that the non-deducibility 
formulation fails to detect this problem. 

10.14 Non-deducibility on Strategies 

The difficulty with non-deduciblity as originally presented is that it takes no 
account of possible malicious behavious by High, maybe in collusion with Low. 
Notice that the counter-example provided by Johnson and Wittbold still satisfies 
non-deducibility in the sense that, assuming that any cipher stream is possible, 
then any plaintext is consistent with the ciphertext that Low observes. 

Having made this observation, Johnson and Wittbold propose a more refined 
version of non-deducibility: they introduce the notion of High strategies and use 
this to define non- deducibility on strategies. In effect High is allowed to make his 
choices at run time on the basis of observations he can make on the system. They 
now require of the system that it satisfy non-deduciblity, whatever strategy High 
may adopt. 

Note that if High had to resolve all his choices ahead of time, for example, 
had to decide on what text to submit to the cipher box before getting a chance 
to observe any of its outputs, then he could not communicate with Low. 

The strategies of Wittbold et al, are really just instances of High CSP pro- 
cesses. As a result, NDoS turns out to be equivalent to our Equation 17. Thus 
the CSP testing approach rather naturally shows up the flaw of non-deducibility 
and leads naturally to the notion of non-deducibility on strategies. 

It is also interesting to consider this example in the context of our power-bi- 
simulation framework. If we think of the r’s as encoding the output of the stream 
cipher, the loose bi-simulation property ensures that High cannot influence them. 
High’s exclusive-oring of predicted bits into the plaintext is tantamount to tam- 
pering with these r’s. There are however some subtle issues here of causality. 
It is not clear that this has really been precisely captured in the formalism. We 
would like to show, for example, that predicting and compensating for the bits 
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is equivalent to High forcing the bits to all equal zero and just using the original 
plaintext. How to capture the act of prediction is rather delicate. 

A formulation that is basically equivalent to Equation 17, called non- 
deduciblity on composition (NDC), can be found in Gorrieri et al, [19] except 
that they use a conventional bi-simulation, so theirs is slightly stronger. Their 
formulation predates ours but it is nice to see essentially the same formulation 
emerging from a different approach. 

An elaboration of testing equivalence, due to Schneider [83], allows for non- 
refusable Low events. In effect we constrain the space of tests to processes that 
are receptive on the L non-refusable events. We could also consider constrain- 
ing the space of High processes and we will return to this in the section on 
generalisations of CSP non-interference. 

10.15 The Lowe Approach to Information Flow 

Lowe points out some of the limitations of existing formulations of NI [48] . None 
seem to give just the right characterisation. He traces part of the problem to the 
way non-determinism can be resolved in CSP. Consider: 

P = h^ STOP III {I STOP n 1' ^ STOP) 

Intuitively this should be secure: the intuition behind the interleave operator 
is that it allows both processes to execute entirely independently. However if 
one considers the LTS, figure 4 upper diagram, we see that there appear to be 
two internal decision points. If these two choices are resolved differently, lower 
diagram, we get an information flow. 

Thus the choice has been resolved differently before and after the occurrence 
of the h. In fact the original CSP specification only really had one choice but 
the LTS representation appears to have two. These are really the same and so 
should really be resolved consistently. The inconsistent resolution has in, effect, 
introduced a spurious causal relationship between the high and the low events 
not intended in the original specification. 

Lowe’s solution is to introduce a demon that ensures that such choices are 
resolved in a consistent way. He introduces additional labels on the LTS to carry 
this syntactic information. This allows him to define the notion of consistent 
refinement and then defines a system to be non-interfering iff any consistent 
refinement satisfies non-interference in the sense of Equation 5 (except that in 
this case a formulation suitable for deterministic systems is appropriate and so 
it is enough to require that the initials match rather than that the ready sets 
match) . 

11 Generalisations 

Thus far we have dealt with the problem of characterising the complete absence 
of information flows through a system. We have seen that even in this com- 
paratively simple situation it is remarkably difficult to arrive at a satisfactory 
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Fig. 4. The Labelled Transition System for P and its “refinement” 



characterisation, even where we have abstracted from questions of time or prob- 
ability. Later we will discuss ways to incorporate these aspects too but in this 
section we will address generalisations of what we have developed so far. 

11.1 Limitations of Non-interference 

Up to now we have used the idea of non-interference to characterise the com- 
plete absence of information flow or indeed stronger, the absence of any causal 
flow. Typically this is too strong for practical applications. We have already en- 
countered the encrypted channel example in which we have causal flow but no 
(significant) information flow. Other situations also call for restricted or con- 
trolled flows. Sometimes this will be due to policy requirements. Downgraders 
are an example in which certain flows are allowed under certain circumstances, 
i.e., the classification of a previously sensitive file is reduced to unclassified by 
a security officer or maybe just due to the passage of time. Another example is 
the downgrading of statistical imformation derived from an otherwise sensitive 
database. 

Sometimes it is more a question of functionality. Typically strict non- 
interference simply isn’t feasible due to clashes of resource demands, etc. A sim- 
ple example is the One Way Regulator or NRL pump. This is a device intended 
to allow information flow from Low to High but not from High to Low. In fact 
some flow from High to Low is necessary to regulate the flow from Low and 
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avoid buffer overffow. For the NRL Pump the bandwidth of the High to Low 
regulating channel is severely restricted. 

More generally there is a trend away from simple MLS-style policies to richer 
styles of policy involving finer granularity and more subtle, dynamic (possibly 
history- or location-based for example) controls of accesses. A simple example 
is the Chinese- Walls-style policy, mentioned earlier, in which an access to one 
class of file denies access to files in a conflicting class. 

In this section we investigate to what extent these policies and requirements 
can be captured in a non-interference framework. There is ,of course, a question 
as to whether such a framework is the appropriate. It may well be that a large 
class of such policies simply do not fit naturally or indeed at all into a non- 
interference framework. It is interesting however to investigate how far we can 
push things. 

The following generalisation of Equation 5 suggests itself: 



V tr, tr' G traces{S) • tr Ki tr' 

Ah{{S II Constrain) /tr) =Ah{{S || Constrain) / tr') (17) 

Firstly observe that « can be an arbitrary equivalence on traces, including 
but not confined to those induced by purge-like functions. We will discuss some 
of the possibilities that suggest thenselves shortly. 

Ah denotes the operator chosen to abstract parts of the interface to S: eager, 
lazy, projection or some mixture. 

Constrain denotes the envelope of behaviours that we are concerned about 
(not necessarily itself a process). High behaviours outside this envelope are al- 
lowed to interfere with Low under such a definition. 

= denotes an appropriate process equivalence. 

Alternatively we could seek to generalise Equation 8: 



Ui ^ U 2 ^ Ah{S II U\ II Constrain) = Ah{S || U 2 W Constrain) (18) 

where ~ denotes a suitable equivalence over High processes. 

Using a testing approach allows us to delimit the space of tests, as in Schnei- 
der’s work, or indeed to constrain the space of high users that we quantify over. 
The latter freedom renders redundant the Constrain term that we used above. 



11.2 Encrypted Channels 

As a first example of how such generalised formulations of non-interference might 
be applied let us return to the encrypted channel in which High feeds a classified 
plaintext into an encryption device and the resulting ciphertext is transmitted 
over some open channel c. We will suppose that the encryption algorithm is 
secure and any keys that might be involved are uncompromised. Indeed we could 
simply assume that we are dealing with a one-time-pad encryption. 
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Here we instantiate the equivalence relation « in definition 18 by: 
« is defined by: 



tr « tr' #(tr |" H) = #(tr' f H) 

that is, plaintexts of equal length are regarded as equivalent, and define Ah 
as projection on the channel c: renaming O’s and I’s to some single symbol, • say. 

A secure encryption channel now passes the form of non-interference defined 
in Equation 17 instantiated with these abstractions and equivalences. Indeed 
the information flow seems to have been quite accurately encoded: Low can 
determine the length of a High message transmitted over c but not its contents. 
It does, however, fail to take account of the fact that Low could detect when 
identical cipher-texts have been transmitted. Presumably if we really are dealing 
with a one-time-pad this is not relevant: the occurence of identical cipher-texts is 
firstly extremely unlikely and secondly signifies nothing. On the other hand, for 
a block cipher in, say, electronic code book mode it could be highly significant. 
To capture this situation we can alter the abstraction applied to the c channel. 
We now allow for process equivalence up to renaming on the alphabet of c. We 
should now think of the alphabet of c as being the bit strings of length I, where I 
is the length of the cipher blocks. For electronic code book mode it is appropriate 
to consider the renaming to be constant on the blocks. This is analogous to our 
encoding of pseudo-anonymity that will be discussed later. 

This last example suggests that it might be useful to consider process equiv- 
alence up to isomorphism, where the isomorphism could be more general than 
simple renaming that we considered above. 

11.3 Downgrading Statistical Information from a Sensitive 
Database 

Another situation that can be encoded rather naturally is one in which unclas- 
sified statistical information is extracted from an otherwise classified database. 
Here we simply choose an equivalence over the state space of the database such 
that states giving rise to the same statistical values are regarded as equivalent. 

11.4 File Editing 

In general many different editing sequences can lead to the same final text, ig- 
noring mark-up features. Certain edit commands will commute, some will negate 
others. Thus, editing sequences leading to identical final texts could be classed as 
equivalent. More generally we could define equivalence under arbitrary rewrite 
rules on traces, but this might hit decidability problems. 

11.5 Operating Systems 

The purpose of an operating system can be thought of as maintaining the illusion 
for each user that they are interacting with their own private system. Thought 
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of this way we see that this kind of requirement is remarkably close to the idea of 
non-interference: the user’s experience of interacting with the system should be 
largely unaffected by the presence of other users. In fact it is possible to get away 
with a weaker requirement here as we are not really worried if the user can infer 
something about the existence and behaviour of other users as long as he still 
gets the functionality he expects. We will see shortly that this is closely related 
to fault-tolerance requirements. We thank John McHugh for this observation. 

11.6 Intransitive Non-interference 

In [74], Rushby discussed what he calls intransitive non-interference. The name 
is actually rather deceptive as it is really about intransitive information flow 
policies. In some situations it is desirable for information to be allowed to flow 
in certain circumstances from H to L via some intermediate process, D say, that 
controls or as least audits the flows. No direct flows from H to L are allowed. 
At first this seems somewhat bizarre as we are in effect stipulating that H ^ D 
and D => L whilst denying H ^ L. 

Rushby gives a couple of examples where this kind of requirement arises: 
downgraders and crypto boxes. Thus, in the case of a down-grader, we allow 
certain files to flow from a high classification to a lower classification but only if 
this is controlled by a downgrading device. 

What really seems to be asserted here is that any flow from H to L should 
be regulated or at least audited by D . Rushby deals with this by introducing an 
ipurge function that no longer acts point-wise on individual events but accounts 
for downgrade events: thus we do not purge events that have been downgraded. 

In [28] Goldsmith and Roscoe critique this, pointing out the Rushby’s for- 
mulation can allow undesired flows. They give an alternative formulation using 
their determinism approach. 

We can use the equivalence induced by ipurge to cast Rushby’s examples into 
our generalised formulation. It may be possible to capture more general forms of 
intransitive information flow policies by suitable choices of traces equivalence. 

11.7 Fault- Tolerance 

Fault-tolerance and masking can also be encoded as non-interference style prop- 
erties: roughly speaking, faults should not interfere with users. This idea crops 
up in [89] and later in [73,87]. For fault-tolerance, however, a weaker version may 
be acceptable as we are not really concerned with the possibility of information 
flowing from the faults to the users. It is thus not necessary in the definitions to 
demand equivalence, refinement is enough: that user functionality is unaffected. 
We are not really concerned if the errors may be able to resolve some of the 
non-determinism seen by the users. Indeed we might want information about 
the error behaviour to flow to the users in the form of warnings, alarms, etc. 

We can thus define S to be tolerant of fault behaviours within a certain 
envelope defined by the process FAULTS by: 
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(-S' Wfauits FAULTS) \ faults Up {S I \ faults STOP) \ faults (19) 

Thus FAULTS {aFAULTS = faults) is a process that encodes the failures 
behaviours we hope to be able to mask or tolerate. For example, for a Byzantine 
agreement algorithm, FAULTS might specify the number and type of failures 
to be tolerated. The RHS of the refinement represents the fault-free behaviour 
of S. We are thus saying that as long as the fault behaviours stay within the 
envelope defined by FAULTS, the system should continue to be a refinement of 
the fault-free system, i.e., continues to provide the same functionality. We are 
assuming that the fault-free system provides the required functionality though 
strictly speaking this would need to be seperately verified against a suitable 
requirements specification. 

Note the use of refinement in this definition rather than equality as used in 
the definitions of secrecy. 

Alternatively, suppose that MLSSLON encodes the mission critical function- 
ality, then we could require: 



5 I \fauits FA ULTS Up MLSSLON (20) 

Thus, even in the presence of a faults scenario within the envelope defined by 
FAULTS the mission critical functionality should remain. We could formulate 
a series of such requirements specifying acceptable degradation of functionality 
under increasingly severe fault scenarios: 



S Wfauits faults. Up MLSSLON, (21) 



11.8 Intrusion- Tolerance 

In principle we could apply this approach to defining intrusion-tolerance with 
something analogous to FAULTS to encode attack scenarios. It is not really 
clear that attack scenarios can be so readily modelled. One could, in principle, 
try to model hostile capabilities (cf security protocols analysis [78]) maybe even 
including cost factors (which, inter alia, might help reduce the search space). 
This remains an avenue for research. 

11.9 Anonymity 

Another property that can be given an elagant non-interference-style formulation 
is anonymity. It is a sort of converse to authentication: authentication is about 
a process being assured of the identity of agents or processes with which it 
is interacting. Anonymity is concerned with preventing identities from being 
revealed. As with authentication, anonymity comes in many flavours depending 
on the application and requirements. 
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It is clear that anonymity has much in common with confidentiality. The lat- 
ter can be thought of as a kind of anonymity over a message space. Indeed our 
Equation 8 could be interpreted as a statement of anonymity: Low cannot dis- 
tinguish which of two possible users are interacting with the system through the 
High interface. This is actually a little strong for the usual meaning of anonymity 
as it requires that any user be indistinguishable from no user. More typically 
anonymity means that you know that an action has been performed but are 
unable to tell who is associated with it. Process algebraic definitions of various 
flavours of anonymity can be found in [85]. 

Pseudo-anonymity can be similarly formulated using a constant permutation 
in the renaming abstraction rather that just projection. This allows correlation 
between pseudonyms across time. 

11.10 Dynamic Separation of Duty 

Earlier we mentioned dynamic separation of duty policies. It turns out that 
such policies can be remarkably simply stated in a process algebra. As a simple 
example, suppose that an agent A can choose between two roles, Role\ and Role 2 , 
but that these are declared mutually exclusive. Once we have expressed these 
roles as CSP processes, we can express this in the CSP notation as: 



A = Rolei □ RoIb 2 (22) 

This gives a Chinese walls style policy for these two roles. Various generali- 
sations to multiple roles and to situations in which the choices are constrained 
in certain ways are obvious. 

11.11 Dealing with Probability 

In principle it seems straightforward to extend the framework presented ear- 
lier to deal with probability by asserting that, for example, the probabilities of 
transitions for related states should be equal. In practice the formalism and ver- 
ification gets cumbersome. One rather natural way to introduce probability is 
using the testing framework: 

Let 



S* := AbstractniS jjff Ui) 

Then we could assert that S is probabilistically non-interfering if: 



V 171 w {72 A T e Tests • 

Prob {Success {Si ||l T)) = Prob{Success{S 2 \\l T)) (23) 

It is far from clear that such a property would be tracable from a verifi- 
cation point of view. However unwinding this definition to some appropriate 
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bi-simulation property might prove more tractable. Here one would be dealing 
with the deltas in probabilities, in particular asserting that probabilities are un- 
changed by the occurrence of High events, as the system evolves. Thus we might 
assert something along the lines of: 

Si^S 2 ^ Prob{Si S[) = Prob{S 2 5^) A (24) 

where Prob{S\ — ^ denoted the probability of a transition labelled h from 

the state to S[. Note that such probabililites will only really make sense 
where they arise due to “essential” non-determinism of the system rather than 
non-determinism that can be resolved by agents or processes interacting with 
the system. This might sidestep the need to assign absolute probabilities to 
transitions. We are grateful to Cathy Meadows for pointing this out. 

11.12 Dealing with Time 

Similarly we could move to a (discrete) timed model, using, for example, the tock 
dialect of CSP, with assertions that the times at which events become available 
to Low are independent of High activity. Again things rapidly get very complex- 
certainly difficult to model-check. Toy examples, for example, encrypted channels 
and maybe the One- Way-Regulator, can probably be pushed through but real 
systems seem out of reach for the moment. 

12 Future Directions 

In this section we outline some directions for future work. 

CSP draws a distinction between internal and external non-determinism. 
These are similar to the don’t know, don’t care style of distinctions drawn in 
many formal methods. We have seen that these two flavours, although they are 
fine for investigating safety and liveness properties, are not enough to capture 
some aspects of information security. In particular, for security, we often need 
to distinguish probabilistic or essential non-determinism. We need to be very 
careful how we refine non-determinism: some non-determinism may be vital to 
security, for example, that arising from a stream cipher. 

We have mentioned a number of approaches to formalising secrecy and hinted 
at possible connections. These need to be more fully investigated and understood. 
Besides these a number of other, recent proposals have appeared that appear to 
be related, for example: Sabelfeld and Sands [79], Mantel [51], and Pinsky [69]. 

We have illustrated how a few requirements and examples can be encoded 
in our generalised form of NIqsp- It remains to try to tackle some more re- 
alistic examples in this framework: the Java security model, databases, smart 
cards. It would also be interesting to investigate more fault-tolerance and even 
intrusion-tolerance examples. It would also appear that a number of non-security 
applications may be usefully addressed using this kind of framework. Indeed it 
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seems that, although these ideas were developed in a security context, they may 
turn out to be at least as useful applied in other contexts. 

A major challenge is to extend such techniques to address time and probabil- 
ity. In principle this seems straightforward. To extend the models in a way that 
remains tractable is far from straightforward. Even without time and probability 
we are straining the limits of what is tractable from a verification point of view. 
On the other hand some of the subtleties that arise are due to the abstraction 
that we make of, for example, time. Thus in some respects models that include 
time may be simpler, at least in a conceptual if not complexity sense. 

12.1 Composition Results 

We saw earlier how using a bi-simulation formulation of non-interference leads to 
a very simple and elegant proof of a composition result. It seems likely that using 
such a bi-simulation formulation of the generalised forms of non-interference 
could similarly lead to simple proofs of compositionality, or alternatively, where 
compositionality fails, shed light on exactly why it fails. Indeed it seems likely 
that one could give a useful characterisation of the class of equivalence relations, 
i.e policies, that give rise to compositionality. 

12.2 Links to Cryptographic Analysis Techniques 

To date the cryptographic definitions of secrecy and the formal definitions that 
we have presented have been developed entirely independently. This is particu- 
larly clear in the area of security protocol analysis in which we understand very 
well how to analyse the strength of the cryptographic algorithms and primitives 
on the one hand and the protocols on the other. The latter tends however to ab- 
stract away from the details of the cryptographic primitives and it is still poorly 
understood how to link the results of the two styles of analysis. As a result it is 
possible for subtle interactions between the crypto primitives and the protocol 
design to slip through analysis. It is quite possible to have a protocol that is 
perfectly secure inplemented with algorithms that in themselves are secure and 
yet the whole is seriously flawed. An example of this can be found in [12]. 

Ideally we would like to be able to tie together the two styles of analysis in 
a way that remains tractable. An attempt to do this is Lincoln et al [47] but the 
resulting framework is very elaborate and it is unclear that anything but rather 
simple examples can be handled. [16] applies the idea of non-interference to the 
analysis of cryptographic protocols. 

Typically the cryptographic definitions and proofs involve reduction argu- 
ments and in some cases testing style definitions. The spy is allowed to submit 
an arbitrary number of plaintexts of his choice to an encryption device and to 
observe the resulting ciphertexts. His choices can be adaptive: they can depend 
on the outcomes of previous experiments. He then finally submits a pair of dis- 
tinct plaintexts and gets the resulting ciphertexts back in an arbitrary order. If 
he is able to guess which ciphertext corresponds to which plaintext with a sig- 
nificantly greater than 0.5 probability the device is deemed insecure, otherwise 
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it is deemed secure. The details of the definition of significantly greater than 0.5 
is rather technical and need not concern us here. See for, example, [30,3]. 

The testing style definitions of non-interference that we have presented above 
may provide a point of contact bewteen the cryptographic and formal methods 
approaches. This is a topic for future research. One can think of non-deducibility 
on strategies in terms of the definition of resistance against adaptive chosen plain- 
text attack: Low is allowed to repeatedly input High behaviours to the system 
and observe the resulting behaviours through his interface. If eventually he can 
glean enough insight into the behaviour of the system to be able to make better 
than evens guesses as to which of a pair of High behaviours has occurred then 
the system is deemed to be flawed. The analogy is rather subtle and there are 
some interesting and illuminating differences. 

12.3 Subliminal Channels and Information Hiding 

Another topic that may be worth investigating using the techniques presented in 
these lectures is that of subliminal channels and information hiding. An attempt 
to formally define such channels is given in Desmedt [14]. It would be interesting 
to see if similar formalisation might be possible using one of the generalised 
forms of non-interference described here. The idea behind information hiding is 
to conceal the existence of information in a message or in data. This involves 
trying to make messages with different hidden information look indistinguishable 
to an observer lacking some appropriate key. It is clear that this has a similar feel 
to some of the properties and policies that we have been trying to capture: that 
behaviours in a given equivalence class be indistinguishable to certain observers. 

12.4 Automated Support 

Besides the theoretical problems that remain there is still the question of de- 
veloping suitable tools and techniques to make the verification of significant ap- 
plications feasible and ideally routine. Significant strides have been made with 
the usability of theorem provers but they still require specialist expertise to use. 
Similarly major strides have been made in the application of model-checking to 
security, see [78]. Model-checking holds out more promise as far as the degree 
of automation typically achievable but here too highly specialised expertise is 
still required to keep the state spaces of the model down to managable sizes. 
Important advances are being made in this area using data independence, for 
example Lazic et al [44], combining data independence and induction techniques, 
Broadfoot [6] , and using predicate abstraction, Saidi [80] . 

12.5 Links to Other Process Algebras 

We have seen that CSP is highly effective at capturing many of the properties 
of concern but also that we have found ourselves hitting the limits of the frame- 
work and having to introduce constructs usually regarded as outside conventional 
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CSP. CCS has also been applied with great effect to information security, see 
the chapter by Focardi and Gorrieri in this volume. It seems likely that no sin- 
gle, existing process algebra will provide us with all the machinery we need for 
information security applications. For example, besides the problems of distin- 
guishing flavours of non-determinism, we need to be able to address mobility. 
Mobility and dynamic networking is an increasingly pervasive aspect of modern 
systems and the research community needs to get to grips with it. A number 
of process algebras have been proposed to address issues of mobility, location 
etc. These include the pi-calculus [64], the ambient calculus [8]. The chapter by 
Andy Gordon in this volume provides more on this topic. We need to see what 
features of these we can adapt or incorporate. 

Asynchronous algebras may also prove fruitful to investigate. The asyn- 
chronous model of communication is similar to our notion of non-refusable 
events. We no longer assume a hand-shaking model of communication in which 
both sides synchronise on an action. Actions are launched into the ether and 
their reception is not guaranteed. This is in many respects a highly appropriate 
model for security applications in a distributed environment. 

12.6 Static and Typing Analysis 

Another rather different approach to defining secrecy is represented by the static 
analysis and typing analysis techniques of Volpano [91] and others, for exam- 
ple [35]. Here non-interference properties are cast in terms of static or typing 
conditions on a programming language or process algebra. 

13 Conclusions 

In these lectures I have sought to give the reader an overview of the evolution 
of mathematical formulations and frameworks for a number of security require- 
ments and policies. We have concentrated on the notion of secrecy or confiden- 
tiality and, in particular, variants of the idea of non-interference as a way to 
formally characterise the absence of information flows. 

The central thesis of these lectures is that characterising non-interference 
reduces ultimately to characterising the equivalence or indistinguishability of 
processes. Several corollaries flow from this observation: 

Establishing how to characterise the equivalence of processes is itself a fun- 
demental and delicate question. Indeed the whole question of what we mean by 
a process is intimately related to what processes should be regarded as equal. 
We should not therefore be too surprised that the problem of what formulation 
of non-interference is correct has remained controversial in the information se- 
curity community for more than 20 years. Indeed it seems likely that there is no 
single, Platonic formulation of secrecy. There are no Maxwell’s field equations 
for secrecy, as it were. 

Which form of process equivalence is appropriate seems to depend on what 
model of computation we adopt and what observations and experiments we deem 



Mathematical Models of Computer Security 



57 



the environment capable of performing on the system. In some cases it will even 
depend on what computational capabilites we assume of the environment. To 
some extent this is just the standard problem facing any exercise in mathematical 
modelling: any model will necessarily be an abstraction of reality. As far as 
possible we seek to make our models faithful, at least as far as the properties 
of interest are concerned. Usually in the interests of tractability, we are often 
forced to make sweeping assumptions and approximations. 

On the more positive side, thinking in process algebraic terms and in terms 
of process equivalence provides many insights and ready-made results. Process 
algebras deal carefully with questions of non-determinism, process equivalence, 
composition and so on. We have seen that the idea of unwinding is closely anal- 
ogous to that of bi-simulation and that many of the historical formulations of 
non-interference can be cast as flavours of testing equivalence. 

We have seen that a process algebraic framework provides an excellent basis 
from which to explore various generalisations of the original, rather binary con- 
cept of non-interference. It also provides an effective framework for reasoning 
about compositionality. 

It should also be acknowledged that we have found ourselves straining the 
machinery of, for example, CSP to try to capture all the subtleties that informa- 
tion security throws up. Indeed it would appear that no existing process algebra 
is entirely suited to capturing all the aspects of information security. We have 
also seen that questions of causality seem not adequately addressed by existing 
process algebras. This has its plus side: the fact that we are testing the limits 
of existing theory when trying to apply it to security problems provides new 
challenges for the theory and stimulates further research. 

Significant advances have been made in recent years in the specification and 
verification of security requirements, protocols, etc,, [78]. I hope at least to have 
conveyed the point that information security raises some fascinating and funda- 
mental challenges both at the theoretical level and at the practical level of tools 
and techniques for verification. 

The concept of non-interference has been a major preoccupation of the infor- 
mation security community for more than 20 years. We have discussed at length 
the problems in obtaining a satisfactory definition. Besides this there remains the 
question of what purpose, if any, non-interference actually serves in the speci- 
fication and development of secure systems. It has been pointed out that no 
real security policy ever mentions the notion explicitly and in any case it is, in 
practice, impossible to realise in any real system: contention for resources means 
that it can never be fully attained in practice. Add to these concerns the point 
that non-interference is such an abstract notion that it is generally extremely 
difficult to map it down to the implementation level. All this might suggest that 
non-interference is little more than a rather elegant, theoretical debating point. 

On the other hand, information security policies are concerned with what 
information flows are allowed and which are illegal. Thus, information-flows and 
their absence are central to such policies. It would seem, therefore, that some- 
thing akin to non-interference, characterising the absence of information flow. 
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must be a fundamental element of any such policy. If we cannot get the speci- 
fication and verification of the absence of certain information flows right, then 
we really do not understand the foundations of our subject. 

It should also be remarked that we are starting to see a number of applica- 
tions of non-interference-like concepts for a far wider class of applications and 
requirements. Maybe the concept will actually prove to be more useful beyond 
the realm of information security, in which it was conceived. The proof of the 
usefulness of the concept will only really be established when it has found an 
effective role in the specification and verification of real applications. 
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1 Introduction 

The rationale of authentication has been a topic of study for about a decade and a 
half. First attempts at formal analysis of authentication protocols were not using 
logics per se, but were certainly logical. Millen’s Interrogator [Mil84, MCF87] 
was a Prolog based tool specifically designed for authentication protocol analysis 
that functioned essentially as a special purpose model checker. Kemmerer used 
the general purpose formal specification language Ina Jo and an accompanying 
symbolic execution tool Inatest to specify and analyze protocols [Keni87]. 

We will focus on logics of authentication, beginning with BAN [BAN89a]. 
However, we will not only be discussing logics per se. We will also be looking at 
the ‘rhyme and reason’ of authentication, the attempts to formalize and define 
notions of authentication and to apply these. Thus, we will also be considering 
the logic of authentication in a broader sense. 

We will not discuss (except incidentally) other formal methods that have 
been applied to authentication. In particular, we will not be describing process 
algebras, automata, automated tools such as theorem provers or model checkers. 
Some of these other approaches are discussed elsewhere in this volume. The 
remainder of this section will provide background on authentication protocols 
and introduce a running example. 

1.1 Background on Authentication Protocols 

In this section we present basic background on the concepts of authentication 
and its building blocks in cryptography. If every device communicating on behalf 
of a person or other entity shared a secret key with every other such device, 
and these keys were never compromised, canceled, unsubscribed, or otherwise 

* This paper is based on a course Syverson taught at the 1st International School 
on Foundations of Security Analysis and Design (FOSAD’OO) in Bertinoro, Italy in 
September 2000. Cervesato was a student there. The work of the first author was 
supported by ONR. The work of the second author was supported by NSF grant 
INT98-15731 “Logical Methods for Formal Verification of Software” and by NRL 
under contract N00173-00-C-2086. 
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expired, then basic authentication protocols might be unnecessary. Clearly this 
is not even remotely the case. It has thus long been recognized that there must 
be some mechanism by which principals that do not share such a secret key, and 
may not even have any knowledge of each other beyond possibly an identifier, 
can establish a key for a secure communication session. 

An authentication protocol is an exchange of messages having a specific form 
for authentication of principals using cryptographic algorithms. They typically 
have additional goals such as the distribution of session keys. Symmetric-key 
cryptography (also called secret-key cryptography) relies on the same key for 
both encryption and decryption. Classic examples include the data encryp- 
tion standard, DES, and its recent successor, AES, the advanced encryption 
standard. (More details about cryptography can be found in any number of 
books [MvOV97, Sch96, Sti95].) Public-key cryptography is encryption and de- 
cryption using different keys (also called asymmetric cryptography). The most 
well known example is RSA. A public key is so-called because it is generally 
available to anyone. Corresponding to the public key is a private key, stereo- 
typically known only to one principal. The private key is used to decrypt the 
message. Because it is uniquely bound to an individual a private key can also be 
used for a digital signature on a message. Typically, different keys and different 
algorithms are used for decryption and digital signatures. For digital signatures, 
the public key is used to verify that the signature is that of the principal bound 
to the public key. Binding is usually accomplished by means of a certificate, 
typically a message asserting such binding, containing an indicator of timeliness 
and signed by a well-known trusted principal (server). 

Security protocols may have any number of intended purposes. Some exotic 
examples are voting, fair exchange of goods or contracts, non-repudiation, and 
anonymous communication. We will focus on authenticated establishment of 
session keys, which is typically necessary for the running of security protocols 
for most other purposes. Authentication is essentially assurance of who you are 
talking to. This can be made more specific in any number of ways: for example, 
you may want to make sure that those obtaining a session key are who they say 
they are, make sure that someone who has the key is currently on line, make 
sure that the principal you think has the key does have it, make sure that the 
principal with whom you think you share the key also thinks he is sharing it 
with you, etc. We will go into more detail on these points in Section 4. For now 
the basic intuition should suffice. 

If a protocol is used for some security purpose, this implies an adversary 
against which the protocol is secure. The standard adversary for formal analysis 
of security protocols was introduced by Dolev and Yao in 1983 and is commonly 
known as the Dolev-Yao adversary [DY83]. It is a very strong adversary, much 
stronger than is typically assumed for secure distributed computation as in, e.g., 
Byzantine agreement. In the Dolev-Yao case, all messages sent from any honest 
principal to any other must pass through the adversary. The adversary can 
read, alter, and redirect any and all messages. However, encryption is treated as 
a black box. The adversary can only decrypt a message if she has the right keys. 
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She can only compose new messages from keys and messages that she already 
possesses. In particular, she cannot perform any statistical or other cryptanalytic 
attacks. Other common terms for the adversary include: attacker, penetrator, 
spy, intruder, enemy, and eavesdropper. Eavesdroppers are typically considered 
as only passive. But, any adversary is often referred to as ‘Eve’. 

1.2 Running Example 

In this section, we introduce an example of an authentication protocol that will 
also be discussed in later sections. Eve’s honest counterparts are traditionally 
named ‘Alice’ and ‘Bob’. The other main principal in this protocol is the server. 
Alice and Bob are assumed to share keys (typically called ‘long-term keys’) with 
the server. Besides the obvious symbols for Alice (A), Bob {B), the server (S'), 
and the keys they share (/c^s, kAB, etc.), the protocol introduces us to 
nonces, i.e., random unpredictable values generated by a principal and included 
in messages so that she can tell any messages later received and containing her 
nonce must have been produced after she generated and sent the nonce. A nonce 
generated by Alice is written ‘ua’- The session key that the server generates for 
Alice and Bob is kAB- Encryption of a message, M, using key k is written ‘{M}k’- 



Protocol 1 (Needham- Schroeder Shared-Key) [NS78] 



Message 1 


A- 


S : 


A,B,ua 


Message 2 


S- 


4 A : 


B : ^AB : i^^AB : -^^kss } ^as 


Message 3 


A- 


B : 


7 kss 


Message 4 


B - 


-4 A : 


{riBjkAB 


Message 5 


A- 


4 B : 


{riB - l}kAB 



In this protocol, Alice indicates to the server that she would like to talk to 
Bob and includes a nonce, ua- The server S sends her a message encrypted with 
the key they share. This message contains her nonce ha (so that she knows the 
message is fresh), Bob’s identifier (so she knows that this is indeed for a ses- 
sion between her and Bob), the session key and an encrypted submessage 
Ajfcjjg to be forwarded to Bob. Alice decrypts this message and forwards 
the submessage to Bob. He decrypts it and sends Alice a nonce ub encrypted 
with the session key to show that he has the session key and to check that she 
does. She decrypts the message, subtracts one from the nonce, re-encrypts, and 
sends it back to Bob, completing the protocol. In the next section, we will set 
out a logic for analyzing protocols such as this. 

1.3 Organization 

In Section 2 we will describe BAN logic, its rules and some limitations and revi- 
sions. In Section 3 we will describe one of BAN’s successors, SVO. Both of those 
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sections will include an analysis of the running example. We will then proceed 
in Section 4 to the ‘rhyme and reason’, presenting formal and informal goals 
of authentication and attempts to define it. We will turn to some of the other 
aspects of authentication protocols in Section 5, where we will look at design 
principles and properties that arise from them, such as fail-stop properties. We 
will also look at ways in which these have been combined with the logical ap- 
proach described in the earlier sections. Another approach to connecting goals 
and logics is considered in Section 6, in which a logical language is used to ex- 
press requirements that are evaluated on a semantic level rather than with a logic 
for that language. Semantics are further tied to the earlier sections by assigning 
meanings to BAN constructs in the strand space model of authentication pro- 
tocols [THG97, THG98b]. Finally, in Section 7 we say a few words about the 
future of formal analysis of authentication protocols. 

2 BAN Logic 

In this section we present an overview of BAN logic. ^ Specifically, we introduce 
the concepts, notation, and rules of BAN, after which, we will give some sample 
analyses. We will end the section by describing some of the extensions to BAN. 

BAN is a logic of belief. The intended use of BAN is to analyze authentica- 
tion protocols by deriving the beliefs that honest principals correctly executing 
a protocol can come to as a result of the protocol execution. For example, Alice 
might come to believe that a key she has received from a server is a good key for 
a communication session with Bob. What ‘good’ means here will be discussed 
below. The approach is to “idealize” the messages in the protocol specification 
into logical formulae. For example, if a server sends Alice a session key inside an 
encrypted message, the key might be replace by a formula that means that the 
key is good. We could then draw inferences based on Alice’s ability to decrypt 
the key and other assumptions that might ultimately lead to the conclusion that 
she believes that the received key is good for talking with Bob. 

BAN has been highly successful in uncovering protocol flaws, needed assump- 
tions, etc., and it is relatively easy to use. A clear motivation in BAN is the math- 

^ ‘BAN’ is derived from the names of its authors, Burrows, Abadi and Needham. It 
is the first in a family of eponymous authentication logics. Versions of this logic 
occurred in many places. The first presentation in a public forum was at TARK in 
March of 1988 [BAN88]. It was also presented at the first CSFW in June of 1988. 
A revised and expanded version of the logic was given at SOSP in December of 
1989 [BAN89b]. Journal versions of this appeared in ACM TOCS [BAN90a] and 
in Proceedings of the Royal Society of London [BAN89c]. The TOCS paper is an 
abbreviated version of the same material. The Proc. Royal Society paper is the 
one typically cited by the authors. Our primary source is the the Digital Systems 
Research Center report [BAN89a], and all descriptions of BAN are drawn from it. 
This SRC report originated in February 1989 and was revised in February 1990 to 
include “The Scope of a Logic of Authentication” , which first appeared at a DIMACS 
workshop in October 1989 [BAN90c]. The February 1989 version of the SRC report 
comprises the Proc. Royal Society Paper. 
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ematician’s credo to make only the needed distinctions and no more. Thus for 
example, the authors simplify reasoning about time by only distinguishing past 
and present epochs. These are not determined by the ephemeral current instant 
but are constant, set once and for all. This gives rise to one of BAN’s central 
concepts, freshness. The other central concept is the aforementioned goodness 
of keys. 

2.1 BAN Notation 

We note at this point that the notation we will use is not that of [BAN89a]. 
Rather it is largely the notation introduced in [AT91] (with the public key no- 
tation introduced in [v093]). It is closer to plain English than the original BAN 
notation, hence a bit more intuitive. For example, compare the following expres- 
sions (the first is original BAN notation): 

P fy Q h #(^) ■^s. P believes Q said fresh{X) 

The language of BAN consists of the following expressions: 

P believes X : 

P received X : message; this may require decryption. 

P said X : 

P controls X : 

fresh (X) : (Read ‘X is fresh’.) X has not been sent in any message prior to 
the current protocol run. 

k 

P < Q : (Read ‘fc is a good key for P and Q'.) k will never be discovered by 

any principal but P, Q, or a principal trusted by P or Q. (The last case is 
necessary, since the server often sees, indeed generates, k.) 

PK{P, k) : (Read P is a public key of P’.) The secret key, k~^, corresponding 
to k will never be discovered by any principal but P or a principal trusted 
by P. 

: Short for “{A}fe/rom P” (Read X encrypted with k (from P)’.) This 
is the notation for encryption. Principals can recognize their own messages. 
Encrypted messages are uniquely readable and verifiable as such by holders 
of the right keys. 

In all of these expressions, “A” is either a message or a formula. As we will see, 
every formula can be a message, but not every message is a formula. 

2.2 BAN Rules 

In an analysis, the protocol is first idealized into messages containing assertions, 
then assumptions are stated, and finally conclusions are inferred based on the 
assertions in the idealized messages and those assumptions. The rules to do so 
are now given. 

The first rule is called “message meaning”. It and “nonce verification” are 
the central rules of BAN. 
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Message Meaning 

k 

P believes P < — > Q P received {X}^. 

P believes Q said X 

“If P receives X encrypted with k and if P believes k is a good key for 

talking with Q, then P believes Q once said X.” [BAN89a] 

Note that this rule does not tell us anything about what submessage (s) P can 
extract from an encrypted message. That will come below under Receiving 
Rules. Rather, this rule tells us what P can discern about who sent the message. 
In applying symmetric keys, there is no explicit distinction between signing and 
encryption. (In BAN, there is also no distinction when applying public keys. Both 
signing and encryption are represented by {X}k- The distinction is implicit in 
the notation for the key used: k or k~^.) 

There is also a public-key version of message meaning. The implied “/rom” 
field in the shared-key case would be redundant in the public-key case since it 
is implicit in the meaning of the notation for binding a public key to a principal 
who originated the signed message. 

P believes PK{Q, k) P received {A}^.-i 
P believes Q said X 



Nonce Verification 

P believes fresh (X) P believes Q said X 
P believes Q believes X 

This rule allows promotion from the past to the present (something said 
some time in the past to a present belief). In order to be applied, X should 
not contain any encrypted text. This rule is the only way for such promotion 
to occur. Since principals are all assumed to be honest and competent with 
respect to following the protocol, it makes sense that anything that a principal 
said recently should be something that he believes. That is, it makes sense for 
assertions, but what if A is a nonce, n? Obviously, it is a stretch of the intuitive 
meaning of belief to say that Bob believes a nonce. It is not necessary that this 
technical use respect all of our intuitions. The goal of the logic is to provide 
something useful for the analysis of authentication protocols, not to formalize 
reasoning about ordinary belief. Nonetheless, [BAN89a] suggests introducing 
a “has recently said” operator. This was in fact done by many later authors; 
although the motivation may have had more to do with making the belief part 
of the logic conform more closely to traditional modal logics of knowledge and 
belief. 
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Jurisdiction 

P believes Q controls X P believes Q believes X 
P believes X 

The jurisdiction rule is what allows inferences that a principal believes a key 
is good, even though it is a random string that he has never seen before. An 
important thing to keep in mind about jurisdiction is the strength of controls 
statements. If P controls X, then P cannot make a mistake in asserting X. In 
BAN, this is somewhat tempered by only allowing inferences , e.g., from Alice’s 
belief that the server controls A B to Alice’s belief that A B. In other 
words, inferences cannot be made about whether a key is actually good, but 
only about whether a key is believed to be good. Later logics, in particular AT 
and SVO, by separating off the axioms of belief, lose this tempering in principle. 
However, in practice this makes little difference. 

/c 

Note that quantifiers are implicit. So “A believes S controls A < — > H” is 

k 

implicit for ^^Abelieves^k.{S controls A < — > H)”. Of course leaving things impli- 
cit leads in principle to some ambiguities. For example, “A believes\/k.(S controls 

B controls A H)” vs. “A believes S controls \/k.{B controls A H)”. 

In practice, these questions do not usually arise in basic authentication pro- 
tocols because nested assertions of jurisdiction are rarely found. As in other 
things, the BAN approach is to ignore complications not encountered in prac- 
tice. If it should become necessary to be explicit, however, then they do so. For 
example, in [ABKL90], nested controls statements occur and the quantifiers in 
those statements are made explicit. 

Belief Conjuncatenation 

P believes X P believes Y 
P believes {X, Y) 

P believes Q believes {X, Y) P believes Q said (X, Y) 

P believes Q believes X P believes Q said X 

The obvious rules apply to beliefs concerning concatenations of messages/con- 
junctions of formulae. We have chosen the neologistic mouthful ‘conjuncatena- 
tion’ to again reinforce the point that BAN makes only the distinctions it needs. 
In this case, concatenations of messages are not distinguished from conjunctions 
of formulae: both are represented as (X,Y) in the above rules. Also, following 
the lead of [BAN89a], we do not list all of the rules; we give only a representative 
sampling. For example, we will not state versions of the last two rules where the 
conclusions are replaced by P believes Q believes Y and P believes Q said Y. 

Freshness Conjuncatenation 

P believes fresh (X) 



P believes fresh{X, Y) 
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For some inexplicable reason, this is a commonly misunderstood BAN rule. Some 
try to deny it; others try to assert the converse rule. Be wary of these mistakes. 
If X is fresh, then any message containing X is fresh in virtue of having X in it. 
But, (A, Y) being fresh tell us nothing about the freshness either of X by itself 
or of Y by itself (because the whole may be fresh in virtue of the other part). 



Receiving Rules: Seeing is Receiving 

k 

P believes P < — > Q P received {X}k P received {X, Y) 

P received X P received X 

A principal receiving a message also receives submessages he can uncover. Here 
is another clever BAN fusion, one that is lost a little in our more English-like 
notation: in BAN the symbol for receiving, ‘<i’, is used to reason about what is 
visible. Thus, what a principal possesses is not distinguished from what he has 
received in some message. Virtually all successors to BAN distinguished the two; 
yet BAN is able to analyze a large number of protocols without this distinction. 

This completes our listing of the rules of BAN. We now describe how to use 
BAN to analyze a protocol. 

2.3 BAN Protocol Analysis 

There are four steps to a protocol analysis using BAN. 

1. Idealize the protocol. 

2. Write assumptions about the initial state. 

3. Annotate the protocol: For each message transmission “P ^ Q : M” in the 
protocol, assert Q received M. 

4. Use the logic to derive the beliefs held by protocol principals. 

As an example, we will go through a BAN analysis of the Needham-Schroeder 
Shared-Key protocol of Section 1.2. 



Example: Analysis of Needham-Schroeder Shared-Key (NSSK) 

The first step is to put the protocol into idealized form. 



Idealized Needham-Schroeder Shared-Key [BAN89a] 

Message 2 S ^ A: {n^, A BJresh(kAB), {A B}kss}kAs ^ 
Message 3 A ^ B : {A B}kBs from S 
Message 4 B ^ A \ {tib, A B}kAB from B 

Message 5 A ^ B : {ns, A B}kAB from A 
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Note that the first message of the protocol is omitted in the idealized form. In 
a BAN idealization, plaintext from the protocol is omitted. Next note the from 
fields. It is always assumed that principals can recognize their own messages. 
Thus, with a shared key, if a recipient can decrypt a message, she can tell who 
it is from. As this is often implicitly clear, the from field is often omitted from 
the protocol idealization. What is inside the encrypted messages is also altered. 
Specifically, the key kAB is replaced by assertions about it. So, Message 2, ide- 
alized, is an encrypted message for Alice from the Server that contains a nonce, 
an assertion that kAB is fresh, an assertion that kAB is good for talking to Bob, 
and an encrypted message to be forwarded to Bob. Note also that in the last 
message — 1 is changed to just riB- This is because the purpose of subtract- 
ing 1 from the nonce is to differentiate it from Message 4. The differentiation is 
reflected in the idealization in the from field. It would reduce informal interpre- 
tation to simply leave ns — 1 in the idealized protocol. But, BAN has no direct 
rule to infer the freshness of ns — 1 from the freshness of n^. So, the change is 
necessary. This was changed in SVO, as we shall see below. 

Once the idealization has been made, assumptions are stated. 

NSSK Initial State Assumptions 

PI. A believes S 

P2. B believes B S 

P3. A believes S controls A B 
P4. B believes S controls A < — > B 

k 

P5. A believes S controls fresh{A < — > B) 

Most of the assumptions should be self-explanatory. PI and P2 express the 
belief in the quality of the long term keys. (Notice that we make no corresponding 
assumptions about what S believes. It would be natural to do so, but we have 
omitted them because, in this case, they are not needed in the derivations that 
follow.) P3 through P5 give the assertions on which Alice and Bob believe that 
the server has jurisdiction. P6 and P7 tell us that each principal believes that 
his/her random value is fresh. 

NSSK Annotated Protocol 

The annotation states assumptions based on the messages in the idealized 
protocol. It can be read directly from the idealization. 

P8. A received {ua.A^AE, B Jresh(kAB) , ^Ifesslfe^s 

P9. B received {A B}kBs from S 
PIO. A received {ns, A from B 

Pll. B received {ub — 1, A from A 

This completes the assumptions needed to analyze the protocol. In the deriva- 
tions below, every line is followed by a justification, i.e., the rule by which it was 
derived and the premise(s) and/or derived formula(e) used in its derivation. 



P6. A believes freshfri a) 
P7. B believes fresfrns) 
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NSSK Derivations 

1. A believes S said {ua, A B,fresh{A {A ^AA, B}kBs) 

By Message Meaning using PI, P8. 

2. A believes fresh{nA, A B,fresh{A ^AA, b), {A ^AA, B}kBs) 

By Freshness Conjuncatenation using 1, P6. 

3. A believes S believes {ua, A B,fresh{A B), {A ^AA, B}kBs) 

By Nonce Verification using 2, 1. 

4. A believes S believes {A B) 

By Belief Conjuncatenation using 3. 

5. A believes S believes (freshA ^AA, B) 

By Belief Conjuncatenation using 3. 

6. A believes {A ^AA^ B) 

By Jurisdiction using 4, P3. 

7. A believes fresh{A <AA^ b) 

By Jurisdiction using 4, P5. 

We have derived Alice’s belief in the goodness and in the freshness of 
We now turn to Bob. 

8. B believes S said A ^AA, b 

By Message Meaning using P2, P9. 

With the assumptions we have made so far this is all we are able to derive 
with respect to Bob’s belief in the goodness of kAB- Unlike Alice, Bob has sent 
no nonce at this point in the protocol. The only way for us to move further is 
if we assume that Bob believes something he has received is fresh. We therefore 
add the assumption that Bob believes that the assertion A ^AA^ b is fresh. 

P12. B believes fresh{A tAA> B) 

This is different than our earlier freshness assumptions since those were all 
based on values that the believing principal had herself generated. This one 
expresses Bob’s belief that a random value someone else has generated is fresh. 
We will return to this odd assumption below after we complete the derivations. 

9. B believes S believes A ^AA, b 

By Nonce Verification using P12, 8. 

10. B believes A ^AlA, B 

By Jurisdiction using P4, 9. 

Unlike for A, for B we were forced to assume B believes fresh{A ^AA^ b) since 
we were unable to derive it. We have now derived Alice and Bob’s first order 
beliefs in the goodness and freshness of kAB- We next derive their second order 
beliefs. 
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11. A believes B said {ubjA B) 

By Message Meaning using 6, PIO. 

12. A believes fresh{nB, A 

By Freshness Conjuncatenation using 7. 

13. A believes B believes {jib^A 

By Nonce Verification using 12, 11. 

14. A believes B believes A 

By Belief Conjuncatenation using 13. 

By similar reasoning, we can obtain B believes A believes A 
but with an important difference. Since Bob believes that A ^3 fresh, there 

is no need for ns in order for him to reach this conclusion. The only role ub 
plays in the protocol is to differentiate Message 4 from Message 5. It does not 
need to be fresh for that. This makes the assumption that Bob believes A ^AE^ 
to be fresh stand out all the more. We now illustrate that the dubious nature of 
this assumption is not just an artifact of the analysis. 



The Denning- Sacco Attack 

In 1981, Denning and Sacco showed how the Needham-Schroeder Shared-Key 
protocol could be attacked if an attacker compromised an old session key [DS81]. 
In the attack specification ^Ea is the attacker masquerading as A. 

Message 3 Ea ^ B : {kAB,A}kss 
Message 4 B ^ Ea ■ {jT-sIfeAB 
Message 5 Ea ^ B : {n'^ - l}kAs 

The attack relies on the fact that Bob has no way to actually be assured that 
Message 3 is fresh. So, an attacker could spend whatever time is needed to break 
the session key kAB- As long as she can do so within the lifetime of kBS, then 
she can run the above attack. Bob will then think he has confirmed sharing kAB 
with Alice, when in reality Alice is not present and the attacker knows the key. 
The attack is not directly uncovered by a BAN analysis of the protocol; rather 
the analysis shows that the protocol cannot achieve any sort of authentication 
for Bob without making the dubious assumption that underlies the attack. 

This concludes our basic introduction to BAN logic and its use in protocol 
analysis. In the remainder of this section, we will set out some of the issues that 
led researchers to expand and modify BAN and the analysis technique. 

2.4 The Nessett Protocol 

In 1990, Nessett introduced the following simple example that “demonstrates 
that a significant flaw exists in the Burrows, Abadi and Needham logic” [Nes90]. 
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Protocol 2 (Nessett) [Nes90] 

Message 1 A ^ B : {nA,^As}fc-i 

Message 2 B ^ A : {nB}kAB 



In the first message, Alice encrypts a session key using a private key, the 
public cognate of which is assumed to be widely known. Bob then send her a 
handshake value encrypted with the session key, • Of course the key is not at 
all good for communication between Alice and Bob because anyone can extract 
it from the first message and use it for communication. But, structurally the 
protocol is the same as one where the first message was encrypted with a good 
key. Here is Nessett ’s idealization of the protocol followed by the corresponding 
annotation, then by the initial state assumptions Nessett presents. 



Idealized Nessett Protocol 

Message 1 A — > B : {n^, A 
Message 2 B ^ A ■. {A 

Annotation Premises 

PI. B received {n A, A B}j^~i 
P2. A received {A B^^ab 



Initial State Assumptions 

P3. B believes PK(kA, A) 

P4. A believes A^ B 
P5. A believes fresh{A 
P6. B believes fresh{n a) 

P7. B believes A controls {A < — > B) 

Note that Nessett assumes Bob to believe that ua is fresh. Therefore, it is 
more naturally thought of as a timestamp than a nonce. We have used this 
notation to more closely follow Nessett^. Based on this idealization and set of 
assumptions, Nessett is makes the following derivations. 



Nessett Protocol Derivations 

1. B believes A said {ua, A B) 

By Message Meaning using P3, PI. 

Specifically, he used “Na”. 
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2. B believes fresh^UA-, A B) 

By Freshness Conjimcatenation using P6. 

3. B believes A believes {ua,A < — > B) 

By Nonce Verification using 2, 1. 

4. B believes A believes A B 

By Belief Conjuncatenation using 3. 

5. B believes A B 

By Jurisdiction using P7, 4. 

This completes the derivations for Bob. We now derive Alice’s second order 
belief in the goodness of kAs- (Her first order belief was assumed.) 

6. A believes B said A B 

By Message Meaning using P4, P2. 

7. A believes B believes A B 

By Nonce Verification using P5, 6. 

Nessett’s Critique of BAN 

Using BAN, one can derive all of the typical BAN authentication goals for 
both Alice and Bob via the Nessett protocol — as we have just done. This shows 
that, according to BAN, kAB is a good session key. But, is not a good 
key. Ergo, BAN is flawed. Nessett traces the source of the “flaw” to the scope 
of BAN. It addresses who gets and acknowledges a key (authentication), but it 
does not address who should not get a key (confidentiality) . 

Burrows et al. respond to Nessett in [BANOOb] by noting that their paper 
explicitly limits discussion to authentication of honest principals. They explicitly 
do no attempt to detect unauthorized release of secrets. Since Alice publishes 
kAB in first message, Nessett’s assumption A believes A q Js inconsistent 
with these stated restrictions. And, from absurd assumptions come absurd con- 
clusions. The logic does not preclude ridiculous assumptions. 

“This seems fair enough; no logic protects against the assumption of 
bad premises. All one can reasonably ask is that, if the premises are 
true, then the conclusion is also true. On the other hand, Nessett could 
counter that illustrative counterexamples are supposed to be obvious; 
that’s what makes them illustrative. If one wants to demonstrate that 
an argument form is invalid, one constructs an argument with that form 
that is clearly invalid. It is hardly fair to say that this shows nothing 
because it’s an obviously invalid argument. That’s the point. The danger 
is that one might use the form to justify an invalid argument that is not 
obviously so. The question remains: On what (extralogical) basis do we 
decide what goes into the premise set? For this case. Burrows et al. would 
no doubt contend that one includes a principal’s belief in the goodness 
of a key only if she has reason to believe that it is good and no reason 
to think that it is not. Of course that is what we would like to do, but 
it is also what we are trying to determine how to do.” [Syv91] 
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Certainly it is much too strong to say that the Nessett example shows the logic 
to be flawed. It does highlight a place where one is expected to rely purely on 
the intuitive reasonableness of assumptions. However, it has not shown that this 
results in either a logical error or a practical vulnerability. 

Still, it would be nice to have a way to capture either formally or at least 
rigorously, the difference between Nessett-type protocols and those not flawed in 
this way. Alice’s action is inconsistent with the meaning of A believes A q 
What is needed is a way to reflect this mathematically [Syv91, Syv92]. Suppose 
we could derive A believes C has kAB (for arbitrary C) . Increasing expressiveness 
would let us formally demonstrate this. 

2.5 Expanding Beyond BAN 

In 1990, Gong, Needham, and Yahalom, introduced a new logic [GNY90] that 
extended BAN. This logic came to be known as GNY, following the precedent 
set by ‘BAN’. In it one can represent possession of keys. So A believes C has kAB 
can be expressed, and possibly derived. GNY also distinguishes available mes- 
sages from received messages. Other important contributions include formalizing 
a principal’s distinction of his own generated messages from others. Analysis in 
GNY also leaves cleartext in idealized protocols, rather than assuming that it 
cannot play a role in authentication. While not specifically formulated as a re- 
sponse to Nessett, this logic allows the expression of key possession and thus 
can express formally that with which the dubious assumption is supposed to be 
inconsistent. By itself this does not guarantee that the needed key possession is 
derivable, nor does it directly express the inconsistency. 

Another response to Nessett that comes closer to directly reflecting the incon- 
sistency of meaning was first given by Abadi and Tuttle in [AT91]. Specifically, 
they presented a BAN-like logic that possessed an independently motivated ac- 
count of meaning in the form of a model-theoretic semantics. This allows one to 
rigorously assess the truth of assumptions (consistent with a protocol). Specif- 
ically, the AT logic was closer to traditional modal logics than BAN, provided 
a detailed model of computation, had a soundness result with respect to the 
model, and was also more expressive (e.g., could express key possession). A tra- 
ditional semantics was much of the motivation for this work. While the published 
soundness result had a mistaken assumption in it, this was a large step towards 
putting BAN on a footing both firmer and logically more traditional. We will 
return to semantics below. 

Another important limitation on BAN is the type of protocols to which it 
can be applied. Diflie-Hellman protocols underly much of modern authenticated 
key distribution. For example, they underly the IETF standard Internet Key 
Exchange (IKE) protocol [DH99], as well as both SSL and TLS — what your 
Web browser uses when it makes a secure connection. Thus, being able to reason 
about such protocols would be quite useful. Paul van Oorschot’s VO logic [v093] 
was designed primarily to add this capability. It is an extension of GNY that can 
be used to reason about Diffie-Hellman type key agreement. In addition, [v093] 
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extended the lexicon of formally stated authentication properties, and formalized 
reasoning about confirmed possession of secrets. We will return to those points 
in Section 4. Right now we turn to a logic that attempts to comprise all of the 
advantages that VO and the other BAN logics introduce. 

3 SVO Logic: Unifying the Predecessors 

In the last section, we saw some of the limitations of BAN, and the extensions 
and variants that were intended to overcome them. Each of the logics, GNY, AT, 
and VO brought a distinct addition. In response to this diversity, Sy verson and 
van Oorschot devised a logic, SVO, that was intended to unify the above pre- 
decessors [Sv094, Sv096]. The intent was not simply to patch on new notation 
and rules adequately expressive to capture the additional scope of these logics. 
This would be both inelegant and potentially unsound. Rather, the intent was to 
produce a model of computation and a logic that was sound with respect to that 
model while still retaining the expressiveness of the various BAN extensions. 

3.1 SVO Notation 

SVO uses the notation already introduced for BAN, with the following main 
additions: 

-K/3 : Negations of formulae are added to the language. 

P says X : but P must have said X since the beginning of current epoch. 

P has X : 

— Initially available to P, 

— Received by P, 

— Freshly generated by P, and 
— Constructible by P from the above. 

The original BAN idea of a public key might be expressed as ‘PK{P,k)’, 
meaning that fc is a public key of P — the matching secret key k~^ will never 
be discovered by any principal but P or a principal trusted by P. In SVO, this 
is refined to cover different types of public key functionality. 

PKjf,{P, k) : k is a public ciphering key of P. Only P can read messages en- 
crypted with k. 

PK^{P,k) : k is a public signature key of P. The key k verifies that messages 
signed by k~^ are from P. 

PKs{P,k) :k is a public key-agreement key of P. A Difiie-Hellman key formed 
with k is shared with P. 

[XJfc : types of public keys, SVO distinguishes signature from encryption. 

: This is no longer short for ‘{X}k from P\ In SVO, it is not assumed 
that principals can recognize their own messages. But it is still assumed that 
encrypted messages are uniquely readable and verifiable as such by holders 
of the right keys. 
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: of [WK96] and is closer to that than to the notation in [Sv094, Sv096]. 
This is used for messages that P doesn’t know or recognize (e.g., {X}fe 
where P does not know k). P will nonetheless recognize {{X}k)*p as the 
same thing if received again, even if he cannot tie it back to any plaintext. 

X from P : 

3.2 SVO Rules 

Like AT, SVO is much more of a traditional axiomatic style logic than BAN, 
GNY or VO. As such there are only two rules. 

Modus Ponens 

tp If — > -i/j 

tj) 

Necessitation 

h f 

h P believes f 

‘h’ is a metalinguistic symbol. ‘T h f' means that the formula f is derivable 
from the set of formulae P (and the axioms as stated below) using the above 
rules, ‘h f' is short for ‘0 h f' and means that (/? is a theorem, i.e., derivable 
from axioms alone without any additional assumptions. We describe derivability 
(i.e. proofs) below in Section 3.4. 

Necessitation is sometimes called by other names, e.g., belief generalization. 
We have given it the name that reflects its origins in alethic modal logic [Chc80] . 
It applies only to theorems of the logic. Like the Belief Conj uncatenation rule 
of BAN, this is often misunderstood and misapplied or improperly criticized. If 
using the assumptions about a protocol it is possible to derive that Q said A, 
it does not follow that P believes Q said X . This is because Q said X is merely 
derivable given the context of this protocol: it is not a theorem, i.e., derivable 
using logic alone. 

Axioms of the logic are all instances of tautologies of classical propositional 
calculus [Men87], and all instances of the following axiom schemata.^ 

3.3 SVO Axioms 
Belief Axioms 

1. {P believes f A P believes (jf ^ il))) P believes ip 

2. P believes f ^ f 

3. P believes f ^ P believes (P believes f) 

4. ^(P believes f) ^ P believes {~^P believes f) 

^ Some of the following are proper axioms, logically. Those containing metavariables 
for formulae are actually axiom schemata. We will generally ignore this distinction, 
referring to all as ‘axioms’. 
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These are classic axioms of modal logic [CheSO, Gol92] that were thoroughly 
analyzed in the early and middle part of the last century. (The classic names 
for them are K, T, 4, and 5 respectively.) As in AT, belief is removed from 
most other axioms, the logic of belief is separated off from the rest of the logic. 
Readers familiar with modal logic will recognize these as the axioms"^ of the 
Lewis system S5 [CheSO]. This logical system is usually taken to characterize 
knowledge rather than belief, so we provide a brief side discussion of the point. 
It may be skipped without loss of continuity. 

Discussion: Knowledge and Belief 

Roger Needham has remarked in conversation that perhaps the biggest mis- 
take they made with BAN was calling it a belief logic. We have already seen 
in the discussion of Nonce Verification in Section 2.2 that BAN-belief does not 
respect all of the intuitions of ordinary belief. Of course no technical usage could. 
Intuitions can be helpful, but they can also lead us from the main task of pro- 
viding a useful analysis of authentication and authentication protocols. More 
detailed discussion of knowledge and belief in authentication logics can be found 
in [Syv92, AT91]. Here we cover a few of the main points. 

The main question in distinguishing knowledge from belief is: If a principal 
thinks that ip, is he always right? If the answer is “Yes”, then we are talking 
about knowledge. If the answer is “No”, then we are talking about belief. That 
is overly simplistic, and philosophical counterexamples are thoroughly plumbed 
in the literature (e.g., look up the Gettier Problem [Mos86]). Nonetheless, it will 
do for our practical intentions. This translates naturally into the main formal 
question: Is it a theorem of the logic that (P believes ip p)7 

This is just the T axiom introduced above as axiom 2. Faced now with this 
technical distinction, we can ask the practical question of which do we want. 
Surprisingly, the answer for our purposes is “I don’t care.” The reason is that 
this has played little role in actual analyses. So, if we don’t care, how did we 
come to add it as an axiom? 

The answer lies in the semantics of the logic. One of the goals of this logic 
was that it have an intuitively reasonable model of computation and semantics, 
and that it be sound with respect to them. Mark Tuttle has noted that we ought 
to build models not logics in trying to capture our notions of authenticated 
communication [Tut]. It turns out that in [Sv096], the semantics of the inten- 
tional operator is based on an equivalence relation. And, it is a classic result of 
modal logic, that this is characteristic of the logic S5. So, it simply falls out that 
the above axioms are all valid in our semantics. But, this is not an important 
practical distinction. In practice, only axioms 1 and 3 seem to play a role. 

Source Association Axioms 

5. {P Q A R received {X from Q}k) (Q said X A Q has X) 

^ The 4 axiom (our axiom 3) is actually derivable given the others and is included for 
tradition and for its intuitive significance. 
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This replaces the Message Meaning Rule of BAN. Note the absence of the 
‘’believes'' operator, and that the axiom applies when any principal R receives 
{X from Q}k- The logical significance of ‘P Q’ is now isolated from that of 
believes. As in BAN, there is also a corresponding public-key axiom. 

6. {PK„{Q, k) A R received X A SV{X, k, F)) ^ Q said Y 

We introduce some new notation here. ‘SV (A, k, Yf means that applying k to X 
confirms that X is the result of signing Y with a private cognate of k. Note that 
this axiom separates out key binding (what principal is bound to the key) from 
key correctness (what key verifies the signature). 

Key Agreement Axioms 

Fo{kp,kQ) 

7. {PKs{P,kp) A PKs{Q,kQ)) ^ P < . Q 

8. (fi = if[Fo{k,k')/Fo{k' ,k)] F^ik' ,k) implicitly names the (Diffie-Hellman) 
function that combines k' with k~^ to form a shared key. 

These are the axioms that characterize Diffie-Hellman key agreement. As 
we mentioned in Section 2.5, this is an important component in widely used 
authenticated key establishment protocols. We give here a brief account of the 
mathematics of Diffie-Hellman. For more details consult a standard cryptography 
text [MvOV97, Sch96]. 



Protocol 3 (DifRe-Hellman) 

1. Assume that Alice and Bob share 

— a large prime p 

— a generator g of the multiplicative group Z* of integers modulo p. 

2. Alice chooses large integer x and computes X = mod p 

3. Bob chooses large integer y and computes Y = g"^ modp 

4. Message 1 A ^ B : X 
Message 2 B ^ A: Y 

5. Alice sets kAB = mod p = g^^"^ mod p (= g^"^ mod p) 

6. Bob sets kAB = mod p = g'^^ mod p (= mod p) 



Receiving Axioms 

9. P received (Ai , . . . A„) ^ P received A^, for z = 1, . . . , n 

10. {P received {A}fc+ A P has k~) ^ P received X 

Here and k— are used to abstractly represent cognate keys, whether for 
symmetric or asymmetric cryptography. In the symmetric case, k~^ = k~ = k. 
In the asymmetric case, k~^ is a public key and k~ the associated private 
key. 

11. (P received [Ajfc) ^ P received X 

Principals are assumed to possess public keys (for convenience). 
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Possession Axioms 

12. P received A — > P has X 

13. P has (Ai, . . . , A„) — P has Xi, for i = 1, . . . , n. 

14. {P has Ai A . . . A P has A„) — *■ P has P(Ai, . . . , A„) 

‘P’ is meta-notation for any function computable in practice by P, e.g., 
encryption with known keys. The meaning of “computable in practice” is in- 
tentionally not formally determined. It could be, e.g., polynomial-time com- 
putable but will be treated as a black box, just as “encryption”, “signature”, 
etc., are in nearly all formal treatments of cryptographic protocols. 

Comprehension Axiom 

15. P believes (P has P(A)) — > P believes (P has A) 

‘P’ is meta-notation for any function that is effectively one-one (e.g., collision 
free hashes) and such that P"*" or F~ is computable in practice by P. Note 
that this axiom does not imply that P is invertible by P. Note also that the 
converse of this axiom is a derivable theorem. 

Saying Axioms 

16. P said (Ai, . . . , A„) — > P said Xi A P has Xi, for z = 1, . . . , n. 

17. P says (Ai, . . . , A„) — s- (P said (Ai, . . . , A„) A P says Xi), for z = 1, . . . , n. 

Freshness Axioms 

18. fresh(Xi) — > fresh{Xi , . . . , A„), for z = 1, . . . ,rz. 

19. fresh{Xi, . . . , A„) — > fresh P(Ai, . . . , A„) P must genuinely depend on all 
component arguments. This means that it is infeasible to compute value of P 
without value of all the Xi. 

Jurisdiction and Nonce- Verification Axioms 

20. (P controls ip A P says p) ^ p> 

21. (fresh{X) A P said A) — > P says X 

Note: Neither axiom refers to belief 

Symmetric Goodness Axiom 

22 . pJ^Q = qJ^P 

3.4 Protocol Analysis 

We now demonstrate how to do a protocol analysis using SVO. We will continue 
with our running example of the Needham-Schroeder Shared-Key Protocol 1. 
A comparison between BAN and SVO analysis is summarized in Figure 1. 
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BAN Analysis 

1. Idealize the protocol. 

2. Write assumptions about initial state. 

3. Annotate protocol. For each message 
“P — » Q : M” of the idealized proto- 
col, assert “Q received M” . 



4. Use the logic to derive the beliefs held 
by protocol principals. 



SVO Analysis 

a. Write assumptions about initial state. 

b. Annotate protocol. For each message 
“P — > Q : M” of the (not idealized) 
protocol, assert “Q received M” . 

c. Assert comprehensions of received 
messages. 

d. Assert interpretations of compre- 
hended messages. 

e. Use the logic to derive beliefs held by 
protocol principals. 



Fig. 1. Protocol analysis steps 



NSSK Initial State Assumptions 

As with BAN, the first assumptions to set out are the initial state assump- 
tions. Unlike BAN, we do not idealize the protocol first. The assumptions are 
virtually the same as the initial state assumptions set out in the above BAN 
analysis, except that the jurisdiction assumption P5 is about jurisdiction over 
freshness of keys rather than jurisdiction over freshness of assertions about the 
goodness of keys. 

PI. A believes S 

P2. B believes B S 

k 

P3. A believes S controls A < — > B 

k 

P4. B believes S controls A < — > B 
P5. A believes S controls fresh{k) 

NSSK Received Message Assumptions 

This step is the same as the annotation assumptions in BAN, except that 
we here use the specified protocol, not its idealization. Amongst other things, 
this means that plaintext is not eliminated, and these premises can be read 
directly from the specification. These premises are not typically used directly in 
derivations. Rather, they are used in the production of comprehension premises, 
which are themselves used in producing interpretation premises. 

P9. S received {A^B,n a) 

PIO. A received {nA,B,kAB,{kAB,A}kBs}kAs 

Pll. B received {kAB, A} kBs 
P12. A received {uB^kAB 

P13. B received {ns — 



P6. A believes fresh{n a) 

P7. B believes fresh{nB) 

P8. B believes fresh{A B) 
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NSSK Comprehension Assumptions 

In this step, we express that which a principal comprehends of a received 
message. The move from the received message assumptions is usually straight- 
forward in practice. In principle, this can be formalized. But a rigorous formal- 
ization makes for a very complicated logic and some of the intuitiveness of SVO 
is lost. Nonetheless, it may be desirable if the intent is to automate as much 
of the reasoning as possible. (Instances of such a formalization can be found 
in [WK96, DekOO].) 

P14. S believes S received {A, B, {nA}*s) 

P15. A believes A received { ua , B, {kAB)*A, MkBs)*A}kAs 

P16. B believes B received {{kAB)*BT^}kBs 
P17. A believes A received {( bb)*t from 
P18. B believes B received {tib — ^}{kAB),B 



NSSK Interpretation Assumptions 

These assumptions are essentially the replacement for idealization. Produc- 
ing them is inherently an informal process. We are asserting how a principal 
interprets a received message (as that principal understands it). This is inher- 
ently dependent on the protocol design. Idealization is one of the most criticized 
and/or misapplied aspects of BAN analysis — bad initial state assumptions be- 
ing the other. While some informality seems necessary in anything like this 
framework, SVO analysis reduces the potential for problems. First, idealization 
is split into comprehension and interpretation. Second, and perhaps more im- 
portant, the interpretational part of the process occurs after annotation rather 
than before. In idealization, there is a natural and correct tendency to interpret 
message components using formulae expressing the intent of the sender. BAN 
annotation then asserts that the receiver receives the intended meaning of the 
sender. By placing interpretation after annotation and comprehension, the focus 
naturally shifts to how the intent of the sender is understood by the receiver. 
That is, focus shifts from the meaning the sender had intended to the meaning 
that the receiver attaches to a received message. 



P19. Abelieves Areceived{nA,B,I^AB)*A,{{kAB-,A'\kBs)*A}kAs A believes A 

{kAB)»A 

received{nA,B,A< > BJresh{{kAB)*A), {{kAB,MkBs)*A}kAs 

P20. B believes B received {(A:ab)*b, ^}fess ^ 

{kAB)*B 

B believes B received {A < > B , fresh{{kAB) *b) , A}kBs 



{kAB)t 



B) 



P21. {A believes A received {{nB) * a} { kAs) * a) ^ believes A 

{kAB)*A 

A believes A received {{riB)*AT A < > 

{kAs)*B 

P22. {B believes B received {ub — ^}{kAB).B ^ (B believes A < *■ B) 

{kAB)*B 

B believes B received {tib — ^,A < > 
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Another point to note about these premises is that they all have conditional 
form. Often, the conditional is only a formal reminder that the interpretation 
depends on the comprehension of the actual receipt of the message. But in some 
cases, e.g., assumption P21, the interpretation depends not just on receipt of a 
message but also on other things, such as assumptions about good keys. 

We have omitted an interpretation premise for the first message because it 
will play no role in the derivations. (The BAN assumption that plaintext does 
not affect analysis is not merely capricious.) 



NSSK Derivations for Alice 

{kAB)*A 

1. AhdievesAreceived{nA,B,A < > B,fresh{I^AB)*A)A^AB,A}kBs)*A}kAs 

By Modus Ponens using P19, P15 

Unlike in BAN, to move from here to Alice believing that the server sent the 
message she received requires several steps. We would have to apply the neces- 
sitation rule to the source association axiom, and also make use of propositional 
reasoning, axiom 1, modus ponens, etc. We will present here only the highlights, 
focusing on the authentication reasoning. We will generally omit reference to the 
rules (modus ponens and necessitation) and will refer to propositional reasoning 
or reasoning using the belief axioms by saying “by Belief Axioms” . 



2 . 

3. 

4. 

5. 

6 . 

7. 

8 . 



A 

A 

A 

A 

A 

A 

A 



believes 

By 

believes 

By 

believes 

By 

believes 

By 

believes 

By 

believes 

By 

believes 

By 



{kAB)tA 

S said {ua,B,A < > B Jresh{{kAB) * a) , {{kAB, A}kss)*A}kAs 

Source Association, 1, PI, and Belief Axioms 

{kAB)*A 

S says {ua,B,A< > B Jresh{{kAB) * a) , {{kAB, A} kg g)* a} k as 

Freshness, Nonce Verification, 2, P6, and Belief Axioms 

(kAB)»A 

A < ^ B 

Saying, Jurisdiction, 3, P3, and Belief Axioms 
fresh {{kAB)* a) 

Saying, Jurisdiction, 3, P5, and Belief Axioms 

(kAB)*A 

B said {{ub)*a,A < > B) 

Source Association, P21, 4, and Belief Axioms 

B has {kAB)*A 

Source Association, P21, 4, and Belief Axioms 

(kAB)*A 

B says ((ns)*A,^ < ^ B) 

Freshness, Nonce Verification, 5, 6, and Belief Axioms 



We could obtain similar results for Bob (assuming we use the dubious assump- 
tion P8, the dubiousity of which is discussed in Section 2.3). This concludes our 
analysis of the Needham-Schroeder Shared-Key protocol. As noted above, one of 
the motivations of SVO was to incorporate reasoning about Diffie-Hellman style 
key agreement. Analyses of two such protocols can be found in [Sv096]. 
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3.5 The Nessett Protocol in SVO 

What about the Nessett Protocol? How does it fare in SVO? Since SVO contains 
both negation and the ability to express possession, it can express who should 
not get keys. This was Nessett’s primary concern about BAN. 

More precisely. In SVO, we can state the requirement 

has kAs) 

where ‘‘E’ is the adversary. Now, given our assumption of a Dolev-Yao adver- 
sary, it is perfectly reasonable, for every message M of every protocol to add to 
the annotation assumptions that E received M . It then becomes trivial for the 
Nessett protocol to derive 

E has kAB 

So, we can prove Nessett Protocol to be insecure. But, what if we could not 
prove E has kAB"! What if this were merely consistent with the protocol not prov- 
able from it? As has been observed, failed proofs sometimes reveal attacks. But 
sometimes they simply reveal our inability to produce a proof. An independent 
semantics would allow us to evaluate the truth of assumptions and requirements. 
SVO was given, indeed based on, such a semantics. We defer discussion of it to 
Section 6. Another question that arises from this discussion is: just what are the 
goals of an authentication protocol? We now turn to this question. 



4 Authentication Goals 

In the previous sections, we have described the syntax of BAN logic [BAN89a] 
and its descendents, most notably SVO [Sv096], and demonstrated how their 
axioms and inference rules can be used to derive new information from the factual 
knowledge specifying a given protocol. For example, this allowed us in Section 2 
to construct a formal argument in support of the idea that, by the end of a run of 
the Needham-Schroeder Shared-Key protocol, the involved parties believe that 
they share a good key for secure mutual communication. As a matter of fact, 
this was one of the intended functionalities of this protocol. In general, we will 
be particularly interested in those derivations that relate the specification of 
a protocol to its intended goals or requirements. 

In the present section, we will be concerned with identifying the authentica- 
tion goals that a given protocol may be expected to fulfill. Rather than directly 
attacking this general problem, we will trace the historical development of this 
quest. We start in Section 4.1 by examining which requirements can be expressed 
in BAN and then, in Section 4.2, we outline the contributions made by its suc- 
cessors, most notably VO [v093]. Limitations in these approaches triggered the 
study of authentication goals per se, independently from their expressibility in 
any given specification language. Replays, i.e. unwanted behaviors due to the 
interferences of multiple runs of a protocol, were soon identified as a major cause 
of unsatisfiable authentication goals, which opened the door to subtle attacks. 
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We examine them in Section 4.3. One of the results that emerged from this 
study is that specification languages such as BAN and SVO are not expressive 
enough to capture some of the authentication goals aimed at avoiding replays. 
The study of the notion of authentication continued, sometimes to tragi-comic 
extremes for most of the 1990’s. We conclude in Section 4.4 by listing some of 
the problems that emerged and the proposed solutions. 



4.1 BAN Authentication Goals 



We have already outlined the way BAN goes about establishing authentication 
properties: given assumptions about the beliefs held by a principal before running 
a given protocol, it allows deducing beliefs that this principal must hold at 
the end of a run. This formal derivation is guided by the idealized protocol, 
which enriches the original specification with explicit descriptions of the intended 
functionality of selected message components, e.g. that a key is fresh or is good 
for communication between two principals. Although idealization is an essentially 
manual process and the logical status of the resulting annotations is dubious, the 
end-product is the vehicle that allows mapping what a principal believes before 
running a protocol to what he believes afterward, as described by the following 
diagram. 

Idealized protocol 

i 



Pre-run 

beliefs 



h 



BAN 



Post-run 

beliefs 



In the case of the Needham-Schroeder Shared-Key protocol examined in Sec- 
tion 2, from assumptions such as that principal A possesses a good key to 
communicate with a server S (“A believes A S” in symbols) and that the 
nonce ua is fresh (“A believes freshen a)”), we deduced that she can legitimately 
think that she is handed a good key kAB to communicate with a receiver B 
(i.e. “A believes A B”). The derivation relies on protocol idealizations such 

as “A i?”. We can indeed instantiate the above schema in the following 
partial diagram: 



•••,A<^ B,--. 

i 

A believes A S 
A believes fresh {n a) 

BAN logic does not define the notion of authentication. Instead, it offers 
means to express the fact that certain properties, clearly related to authentica- 
tion, should be valid at the end of a message exchange, assuming certain premises 
hold. We call them authentieation goals, and use the phrasing authentieation as- 
sumptions for the premises they depend upon. BAN logic views authentication as 



A believes A 



kAB 



B 



The Logic of Authentication Protocols 



87 



a protocol dependent notion: therefore, different protocols will generally require 
different authentication assumptions and achieve different authentication goals. 
We schematically describe BAN’s approach to authentication in the following 
diagram, a final evolution of pictures above: 

Idealization of protocol V 

i 

Authentication 
assumptions for V 

The realization that authentication is a protocol dependent notion leads to our 
first observation on authentication: 



h 



BAN 



Authentication 
goals for V 



1. There is not a unique definition of authentication that all 
secure protocols satisfy. 



Although authentication goals depend on the protocol at hands (and on its 
assumptions), certain goals recur fairly often. In particular, all BAN analyses of 
key distribution protocols have some of the following formulae as conclusions: 

— A believes A ^ 

— B believes A q 

— A believes B believes A B 

— B believes A believes A i-AE, B 

Clearly, other goals are possible, e.g. about beliefs concerning public keys. But 
they do not arise in the examples considered in [BAN89a], in which public keys 
are always a means to produce session keys in the form of shared keys, rather 
than the objects about which one would try to establish goals. 

On the other hand, there are good key distribution protocols^ for which some 
of the above goals are not applicable. Consider for example, the Wide-Mouthed 
Frog Protocol [BAN89a, CJ97], described below: 



Protocol 4 (Wide- Mouthed Fhog) [BAN89a, CJ97] 

Message 1 A^S: {TA,B,kAB}kAs 

Message 2 S^B: {Tg, A, /c^Blfess 



The initiator A wants to communicate securely with another party B. She 
achieves this by generating a key kAB and sending it to a trusted server S to- 
gether with her intention to communicate with B. The server simply forwards 
this key to B, together with the identity of the generator. The components 
Ta and Tg are timestamps. The first message is encrypted with a key kAs that 
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A shares with S, which ensures that its contents are not accessible to any other 
party. Similarly, the second message is encrypted with key kss that B shares 
with S. By the end of a run, only A, B and S are expected to know k^B- 

Since A generates the key she has jurisdiction over its freshness and 
intended use. Therefore 

A believes A B 

is an assumption as well as a goal for the protocol. We leave it to the interested 
reader to devise the other relevant assumptions of the Wide-Mouthed Frog Pro- 
tocol 4 as well as the form of its idealization. Provable goals of this protocol 
include 

B believes A B and B believes A believes A B 

(again, the formal derivation is left to the reader). It should however be observed 
that the formula 

A believes B believes A B 

although taken from the above list of typical goals, is not provable. Indeed A can- 
not hold any belief about i?’s beliefs since she is not the recipient of any message 
in this protocol. 

4.2 VO Authentication Goals 

As reported in Section 2, BAN was shown to have a number of shortcomings, 
soon to be fixed by a succession of proposals. While early extensions such as 
GNY [GNY90] and AT [AT91] concentrated on providing a finer modeling lan- 
guage for protocol actions, the logic VO [v093] also enriched the lexicon of 
formally stated authentication goals. At the same time, it exposed nuances of 
the still vague notion of authentication that BAN and its early successors were 
unable to express. Altogether, VO provided a better understanding of what au- 
thentication actually is. 

In this section, we present the various forms of authentication available in 
VO. Rather than trying to be completely faithful to [v093], we will incorporate 
some of the adjustments made in later proposals. For simplicity, we will formalize 
the notions in this section using the syntax of SVO [Sv096], already introduced 
in Section 3. 

We first need to introduce some syntax. VO expresses the fact that a key k is 
an unconfirmed secret for a principal P to communicate with another principal 
Q as 

P^Q 

Similarly to BAN’s key goodness, this expression means that only P and Q (and 
third parties trusted by both) know k. It also implies that P has access to this key 
(e.g. by having received it in a message), but does not enforce a similar require- 
ment on Q: this principal may not be aware of k. It was later observed [Sv096] 
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that this expression can be given the following simple definition: 

P^Q = {pJ^QAPhaskf 



It should be observed that key confirmation is not symmetric. Indeed, P < — > Q 

k— 

is not equivalent to Q < — > P. 

Given this definition, VO distinguishes the following six forms of authentica- 
tion: 

Ping authentication captures situations where a principal P wants to know 
whether an interlocutor Q is alive. It is expressed as the following formula, 
where X can be any message. 

P believes Q says X 

Observe that not only should Q have uttered something (V), but he should 
have done so recently, as enforced by the use of says as opposed to said. 

Entity authentication further requires that P’s interlocutor Q said something 
relevant to their present conversation. Given some information Yp known to 
be fresh to P (e.g. a nonce), entity authentication mandates that Q recently 
sent a message F{X,Yp) from which it is manifest that Q has seen Yp and 
has processed it. This is captured by the following formula: 

P believes {Q says F{X,Yp) A fresh (Yp)) 

Suitable message transformation functions F must possess the following 
properties: 

— F is effectively one-to-one, by which we mean that for any choice of the 
arguments X and F, if F{X,Y) = Z, it is computationally infeasible to 
find values X' and Y' different from X and Y such that F{X' , Y') = Z. 
As in [MvOV97], p. 324, the meaning of ‘computationally infeasible’ is 
“intentionally left without formal definition” , to be interpreted relative 
to an understood frame of reference. For example it might mean that 
there is no algorithm that terminates in a time polynomial in the size of 
the argument of F that computes such X' and Y' . But this is only one 
possibility. 

This definition also indicates that F genuinely depends on Yp, in the 
sense that it is computationally infeasible for an adversary to produce 
an alteration Yf, of Yp that yields the same result, even if he controls 
the choice of the first argument of F. 

— F IS computable in practice by Q. This too is left without precise defini- 
tion. One example would be, given X and Yp, Q can compute F{X, Yp) 
in polynomial time. 

® In BAN, a principal A could only refer to a key k by believing some property of it, 
most notably its goodness, or by receiving it in a message. GNY [GNY90] remedied 
to this deficiency by allowing one to talk about entities possessed by a principal. 
Here we adopt the AT syntax “A has k” introduced in Section 3. 
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— P can effectively verify that the received value F{X,Yp) has actually 
been constructed by using Yp. This can be achieved in two different 
ways: 

• P can in practice compute enough of the inverse of F to expose the 
use of Yp. This is the case, for example, if F{X, Yp) = {Yp}x and X 
is P’s public key. 

• P has access to X (and Yp), can effectively compute F{X,Yp), and 
can verify whether the result corresponds to the value transmitted 
by Q. An example of this situation is when P is a hash function 
and X is known to P. 

Secure key establishment indicates that a principal P believes that he has 
a good key k to communicate with a counterpart Q. Given the above notion 
of unconfirmed secret, this goal is easily expressed by the following formula: 

P believes P Q 

Key freshness simply requires that a principal P believes a key k to be fresh: 

P believes fresh{k) 

Mutual understanding of shared keys applies to situations where a princi- 
pal P can establish that an interlocutor Q has sent a key k as an unconfirmed 
secret between the two of them (from Q’s point of view). This is formalized 
by the following formula: 

P believes Q says (Q ^ — > P) 

Key Confirmation is intended to describe scenarios in which a principal P be- 
lieves that an interlocutor Q has proved to have received and successfully 
processed a previously unconfirmed secret key k between the two of them. 
Similarly to the case of entity authentication, we capture the “confirmation” 
aspect of this definition by requiring Q to return k to P, modulo the appli- 
cation of a function P that is effectively one-to-one, computable in practice 
by Q, and effectively verifiable by P. We have the following formal definition: 

P believes (P — > Q AQ says F(k)) 

It should be observed that key confirmation is not the same as the BAN-style 
second-order belief “P believes Q believes P Q” , which may wrongly im- 
ply that Q believes that fc is a good key for them to communicate. For a sim- 
ilar reason, it differs from mutual understanding of shared keys “P believes 
Q says Q ^ — > P” . 

These definition shed substantial light on the notion of authentication. How- 
ever, they also raise further questions, a clear indication that VO has moved 
our understanding of authentication forward, but also that it has not exhausted 
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the subject. A closer look at entity authentication and mutual understanding of 
shared keys will reveal some problems, that will be addressed in the rest of this 
section. 

Given actual principals A and i?, the intended meaning of the entity authen- 
tication goal 

A believes {B says F{X, Ya) A fresh{YA)) 

is that A is engaged in a protocol run with B and she thinks that B said some- 
thing in response to the nonce Ya she generated for this run. Observe however 
that this goal does not impose any constraint on i?’s assumptions; an intruder 
could indeed have rerouted messages in such a way that Ya entered a conver- 
sation B was having with a third principal, C say; B may then have freshly 
sent F{X, Ya) to C, but the intruder altered the intended course of this message 
so that it reached A instead. This undesirable behavior passes the above entity 
authentication test. 

Consider now the following goal, an instance of the mutual understanding of 
shared keys: 

A believes B says {B < — > A) 

The concern raised above for entity authentication does not apply here since the 

k— 

presence of the unconfirmed secret expression B < — s- A indicates that B is aware 
of the fact that k is intended to communicate with A. There is however room for 
attacks: again, an intruder may have rerouted messages so that B thinks that 
the key k is being used in a run r he is conducting with A, while A believes she 
is using it in a different run r', although with B. Again, this potentially harmful 
behavior satisfies the above notion of mutual understanding of shared keys goal. 

Both scenarios arise as (intruder-assisted) misunderstandings: the involved 
principals are participating in an apparently legal run of the protocol, but not 
in the same run and not necessarily with each other. Both situations involve an 
interleaving of at least two protocol runs, with the intruder altering the message 
routes to unduly connect these otherwise independent runs. Such situations are 
called replays and will be examined in detail in the next section. 

4.3 Replay Attacks 

As we just discussed, a replay attack is characterized by an intruder opportunisti- 
cally bending the path of messages belonging to different runs of a protocol, pos- 
sibly after making minor changes to the messages themselves. An in-depth study 
of the different incarnations of the notion of replay was undertaken in [Syv94]. 
We present this analysis and use it to measure the expressiveness of the authen- 
tication logics from Sections 2 and 3. Two attempts at covering more replay 
attacks, one that refines the BAN model of time and one that introduces the 
notion of role, are then discussed. 
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A. Run external attacks 

1. Interleavings 

(a) Deflections 

i. Reflections 

ii. Deflections to a third party 

(b) Straight replays 

2. Classic Replays 

(a) Deflections 

i. Reflections 

ii. Deflections to a third party 

(b) Straight replays 



B. Run internal attacks 

(a) Deflections 

i. Reflections 

ii. Deflections to a third party 

(b) Straight replays 



Fig. 2. A full taxonomy of replays [Syv94] 



A Taxonomy of Replays 

Syverson, in [Syv94] , proposes two orthogonal classifications of replays, which 
formalize the observations that these misbehaviors derive from the interleaving 
of multiple protocol runs, and that the intruder redirects messages among them, 
respectively. We will now examine them in detail. The overall combined taxon- 
omy is displayed in Figure 2. 

A first way to approach replay attacks is to distinguish them on the basis 
of which runs the replayed messages are taken from. This materializes in a run 
taxonomy [Syv94], which immediately branches into the following two classes: 

A. In a run external attack, the replayed message comes from outside the current 
protocol run. This option involves the execution of at least two runs, which 
can be either concurrent or sequential, as indicated by the next branching 
point in this taxonomy: 

(1) An interleaving attack requires two or more runs to take place contem- 
poraneously. The intruder uses the different runs in turn as oracles to 
answer the challenges set forth by the others. A popular example of 
this form of replays is given by Lowe’s attack [Low96] on the Needham- 
Schroeder Public-Key Authentication Protocol 7, which we will examine 
in Section 4.4. 

(2) An attack that involves external runs but without the requirement that 
they should be contemporaneous is called a classic replay. The intruder 
remembers messages sent back and forth during previous runs, and op- 
portunistically replays them to mount an attack on the current run. We 
have seen an example of classic replay in Section 2 as the Denning-Sacco 
attack [DS81] on the Needham-Schroeder Shared-Key Authentication 
Protocol 1. 

B. An attack can also result from opportunistically replaying messages from the 
current protocol run. These are known as run internal attacks. An example 
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involving the Neuman-Stubblebine repeated authentication protocol [NS93, 
CJ97] has been exposed by Syverson in [Syv93b] and by Carlsen in [Car93]. 

Another way to look at replay attacks examines which messages are rerouted 
by the intruder, and how this is done. The resulting classification is known as the 
destination taxonomy [Syv94]. Let us first consider who the replayed message 
was intended for: 

a. The first situation, called deflection, redirects the replayed message to a prin- 
cipal different from its intended recipient. This situation can be further re- 
fined in the following subcases: 

(i) First, the replayed message can be sent back to its sender. This is called 
a reflection attack. 

(ii) We can also have a deflection to a third party, in which the message in 
question is redirected to a principal that is neither the intended recipient 
or the originator. 

b. An intruder can mount an attack by channeling a message to its intended 
destination, but with some delay and possibly in a different run of the pro- 
tocols. This is known as a straight replay. 

We will now demonstrate the various forms of destination attacks by examining 
a well-known disruption on the a variant of a draft protocol due to Yahalom, 
a version of which was ultimately published in [Yah93]. The variant we consider 
here was first presented in [BAN89a]. By virtue of this iterated genesis, we call 
it the BAN-Yahalom protocol. It is specified as follows: 



Protocol 5 (BAN-Yahalom) [BAN89a] 



Message 1 


A- 


B : 


A, HA 


Message 2 


B - 


-4 S : 


B,nB,{A,nA}kBs 


Message 3 


S- 


4 A : 


Ub, {B, kAB, nA}kAS,{^, kAB,nB}kBS 


Message f 


A- 


4 B : 


{A, , TIb ’ {.^B } kAB 



The initiator A and the responder B rely on a server S to generate a key kAB that 
would allow them to communicate securely. The long term keys kAs and kss 
guarantee the mutual authentication of the server and the principals A and B, 
respectively. Intentionally, the third message indirectly authenticates i? to A by 
having the server encapsulate both B’s identity and A’s fresh nonce ua in the 
message {B, n^lfcAs- The fourth message authenticates A to i? by encrypt- 
ing B’s nonce ng with the newly acquired (and supposedly secure) key kAB- 
This protocol is subject to the following attack, first presented in [Syv94], 
which makes use of three protocol runs, which we distinguish by using different 
numerals and indentations. The intruder is given the name E (the Eavesdrop- 
per), and we write Ep to indicate an action of the attacker while impersonating 
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principal P. The attack unfolds as follows: 



1. 


A - 


-^Eb 


A,ua 


I. 


Eb 


A 


B,ua 


II. 


A - 


Es 


A,n'A,{B,nA}kAs 


ii. 


Ea 


S 


A,nA,{B,nA}kAs 


Hi. 


S - 


^Eb 


UA^ {A, kAB : Ba} kss ; i ^AB j kAS 


3. 


Es 


A 


Be, {B, kAB, «A}fe^s> kAB, BA}kBS 


4. 


A - 


^Eb 


{A, kAB , Ba} kss'i \.BEy kAB 



In line (1), ^ generates the nonce ua to communicate with B. The outgoing mes- 
sage is intercepted by E and replayed to A in line (/) after altering its postulated 
originator to B. In A’s view, this is the first message of a different run, with B as 
its originator, and therefore she responds as expected by generating a nonce 
and forwarding the message (^, n^, {i?, to the server in line {II). The 

intruder alters this message en route by replacing the nonce with ua in line 
(a). Logically this is part of a third run of the protocol (the server has no reason 
to suspect that this run lacks its first message). The server performs its task 
on line (in) by generating the message (ua, {A, «A}fess: ^ab, nA}kAs)- 

These two inner runs are left dangling. We return instead to the outer run, 
where A is expecting a reply from S to her indirect request of line (1) via B. In 
line (3), the intruder replays the message captured in line {Hi) after substituting 
a nonce tie oi his own in place of the outermost occurrence of ua- This message 
has the expected form, and therefore A replies in line (4) as dictated by the text 
of the protocol. 

Although no key is revealed to the intruder E, an attack has taken place 
since A believes she has been talking to B without this principal even partici- 
pating in any run. This is clearly a failure of authentication. In order to mount 
the attack, the intruder makes use of three replay techniques: 

— Going from lines (1) to (/), we first have a reflection of the nonce ua back 
to A. 

— Going from lines {II) to {ii), we have a straight replay of the message com- 
ponents A and {B,nA}kAs across two different runs of the protocol. 

— Finally, going from lines {Hi) to (3), we have a third party deflection of the 
encrypted components {A, kAB,nA}kBs and {B, Iab, BAjkAs from S' to A 
and away from B. 

Figure 2 integrates the run and destination taxonomies of replays, showing 
in this way all possibilities for a replay attack. This is therefore a complete 
classification. 



Gauging Expressiveness 

The above taxonomy of replays gives a clear view of the different ways an 
intruder can take advantage of the messages exchanged in one or more runs of 
a protocol to mount an authentication attack. This minute classification is also 
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an excellent basis to measure the expressive power of various protocol analysis 
formalisms: an ideal system would successfully apply to all points in Figure 2. 
Most proposals cover instead a more spotty spectrum. In this section, we will 
make use of this taxonomy to outline the strengths and weaknesses of the au- 
thentication logics discussed in Sections 2 and 3. The results of this analysis 
should be taken with a grain of salt: there are cases where a formalism does not 
have mechanisms to systematically expose a certain class of attacks and yet has 
tackled specific instances of this class. 

We shall first consider BAN logic [BAN89a] introduced in Section 2. Freshness 
is the only mechanism available in BAN to distinguish a run from another. 
This is a very weak mechanism indeed, since its effect is limited to temporally 
partitioning protocol actions into recent (i.e. provably fresh) and old. Therefore, 
freshness alone cannot hope to reveal run internal attacks, nor any form of 
interleaving attack. It instead focuses on the portion of the run taxonomy [Syv94] 
that we have called classic replays. 

Although by assumption rather than by analysis, BAN captures a similarly 
small fragment of the destination taxonomy [Syv94]. First, recall that BAN 
expects a principal to recognize messages he/she has said. This is equivalent 
to limiting the scope of the verification process to protocols that are immune 
to reflection attacks. Second, the notion of a (shared) key k being good for two 
principals A and B to communicate, ‘A B\ similarly circumvents deflection- 
to-third-party attacks. What is left of the destination taxonomy is the category of 
straight replays and some deflection-to-third-party situations that involve public 
keys. 

In summary, the expressiveness of BAN relative to Figure 2 is limited to the 
zones marked “straight replays”, and the area pertaining to “classic replays” 
among the run external attacks. In spite of this restricted scope, BAN has been 
successfully used to perform a large number of analyses. 

The logic GNY [GNY90] corrects the inability of BAN to talk about reflection 
attacks by providing syntax (an asterisk “*”) to flag a message as “not originated 
here”. The other limitations of BAN remain. Surprisingly they are not addressed 
by the successors of GNY, namely AT [AT91], VO [v093], and SVO [Sv096]. 

We can sum up these observations as follows: none of the discussed logics 
exhausts or fully expresses the notion of authentication. In particular, since all 
of them, starting with BAN, are equipped to reason about freshness, we deduce 
that, in general, authentication problems cannot be reduced to enquiries about 
freshness. This leads to our second observation on authentication: 



2. Freshness is not rich enough to express all the kinds of authentication. 
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Adding Time to Increase Expressiveness 

As mentioned above, BAN and its successors rely on a simplicistic view of 
time that only distinguishes “recent” events from “old” actions. Freshness dec- 
larations draws the temporal line separating them, although recent messages 
almost always pertain to the current run. A finer use of time in protocol anal- 
ysis was proposed in [Syv93a] with the introduction of the modality “S’, read 
“previously” . This allows not only breaking the time-line in more than two seg- 
ments, but also expressing the fact that event occurrences should have happened 
according to a certain order. For example, a requirement such as 

A received {B, riA\kAs ^{B said {A, riA}kBs) 

means that if A receives the message on the left-hand side of the implication, 
then B has previously sent the message on the right-hand side. The added tem- 
poral operator has therefore the additional effect of capturing a form of causality 
between events. 

A natural question to ask is whether the addition of the above modality 
to BAN or SVO is sufficient to address all forms of replay in the taxonomy in 
Figure 2. The answer is unfortunately negative: at least straight replays are not 
covered. 

In order to demonstrate this point, we will rely on the protocol below, first 
presented in [Sne91]. The system it models consists of a master computer M and 
a collection of sensors S\, ... ,Sn, each controlled by a microprocessor. The mas- 
ter computer periodically queries the sensors. The protocol is aimed at authen- 
ticating the order and timeliness of their reports. 



Protocol 6 (Snekkenes) [Sne91] 


Message 1 M ^ Si 


Query(z,j) 


Message 2 Si ^ M 


[nij,Query(f, j), Answer(f,j)J^-i 


Message 3 M ^ Si 


\nij\ fe-i 



In the first message, M sends a query Query(i, j) to sensor Si, where j is a pro- 
gressive number. In the second message, the invoked sensor, Si returns an an- 
swer Answer(i,j) together with the original query and a nonce aimed at 
ensuring the freshness of the reply. The origin of this composite message is guar- 
anteed by having Si sign it with its private key k~^ . Upon receiving this message, 
M responds by signing the nonce with his own key . 

This protocol is not immune to straight replay attacks, even if M keeps track 
of all used and (correctly) assumes these values are fresh. An intruder can 
indeed subvert the result of this protocol by intercepting a query Query(i,j) on 
its way from M to Si, forwarding it multiple times to Si, and letting through 
to M the most desirable answer. 

This attack can be neutralized by reversing the order of the last two messages 
of this protocol. Consequently, the nonce riy is now generated by M rather than 
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by Si- Moreover, it is now the sensor’s duty to memorize the nonces, verify 
their freshness, and limits its answers to one per nonce, to preclude replays. The 
master computer shall maintain an association between nonces and queries to 
prevent the subversive rerouting of signed nonces to sensors different from the 
one they were intended for. 

Snekkenes observed in [SneOl] the rather unsettling fact that the BAN analy- 
sis of both variants of this protocol is same. He furthermore proved that a similar 
limitation holds for any two variants of a given protocol that differ only by the 
order of the exchanged messages: 

Theorem 1. (Snekkenes ’91) 

1. Let V and V' be protocols composed of the same messages, although not 
necessarily in the same order. 

2. Assume that V can be shown to satisfy some goal G given certain assump- 
tions A. 

3. Furthermore, assume that V' is demonstrably insecure. 

Then, V' can also be shown to satisfy the goal G given the assumptions A. 

This result was rigorously proved in the context of an annotated sequent 
calculus for BAN logic. 

The above theorem states that extending BAN queries to faithfully account 
for the causal ordering of protocol actions is not sufficient to prevent all forms 
of replay attacks. This leads to our third observations on authentication: 



3. Correct causal order and source of a message are not strong 
enough for all authentications. 



Roles in Cryptographic Protocols 

The most visible effect of the introduction of the temporal operator <S> in the 
previous section was to extend the language used to express and validate protocol 
requirement. A similar proposal in [Bie90] focused instead on the language used 
to specify a protocol. 

In [Bic90], protocols are described in the logic of knowledge and time CKT5, 
which enriches a fragment of first-order logic with the modal operator KA,t and 
a suitable set of axioms. The intended meaning of a formula of the form ATa,* T 
is that at time t principal A knows that p holds. The use of proper quantifiers 
over time variables allows capturing the relative temporal ordering of events, 
similarly to what we have observed with < 8 >. 

The introduction of this modality makes it possible to put strict temporal 
constraints on the actions that a principal participating in a protocol is allowed 
to perform. This permits expressing scenarios where, for example, if A sent 
TOi and A received m 2 , then the next action of A is to send m 3 . In this proposal, 
the protocol actions available to a principal are organized in a role, given as 



98 



Paul Syverson and Iliano Cervesato 



the sequences of message transmissions that this principal is going to perform, 
possibly in response to the reception of some well-defined messages. A protocol 
specification is then presented as a set of roles, one for each participating prin- 
cipal. It should be observed that this approach constitutes a radical change of 
course with respect to the BAN-like specification methodology discussed so far: 
in these languages, a protocol was described by listing the messages exchanged 
during an expected run, while roles focus on the individual view of each principal, 
independently from any run. 

The CTK5 specifications given in [Bic90] allowed each honest principal par- 
ticipating in a protocol to play exactly one role. It was shown in [Sne92] that 
this restriction could give an incorrectly clean bill of health: attacks that re- 
lied on having the same principal act both as an initiator and a responder, for 
example, were missed. This same paper corrected this limitation by upgrad- 
ing the one-to-one relation between roles and principal proposed in [Bie90] to 
a many-to-one correspondence. Therefore, a given principal was now associated 
with a set of roles, an entity also known as a multi-role. Differently from roles, 
multi-roles could, for example, express the necessary conditions to set up the 
attack on the BAN-Yahalom protocol discussed in Section 4.3. 

The CKT5 formalization of roles and multi-roles used in [Sne92] was later 
simplified in [Car94], which also gave an algorithm to generate CKT5 role spec- 
ifications from the BAN-like “standard notation” of a protocol. 

Clearly, if the protocol at hand is constrained in such a way that every honest 
principal can play at most one role, then no multi-role flaws can be uncovered. 
Even in this limited setting, the use of CTK5 as a specification language does not 
prevent the possibility of all attack. The Snekkenes Protocol 6 from Section 4.3 
is subject to the same attack even when expressed in this language. We can 
therefore strengthen our last observation on authentication as follows: 



4. Correct causal order and message source, and freedom from multi- 
role flaws are not strong enough for all authentications. 



4.4 A Child’s Garden of Authentications 

Starting with the most common authentication objectives of BAN logic 
[BAN89a], the previous section has described the contributions made by var- 
ious researchers to the formalization and understanding of the notion of authen- 
tication. We saw how these original goals were extended in languages such as 
VO [v093] and SVO [Sv096]. We then categorized attacks relative to the tax- 
onomy of replays defined in [Syv94] and finally discussed a series of proposal 
aimed at repairing specification [Bic90, Snc92, Car94] and requirement [Syv93a] 
deficiencies of the BAN family of logics. Yet, not all attacks could be nailed 
down. 

By this time, we were in the mid 1990s and the notion of authentication was 
looking like a more and more distant chimera. The research toward this holy 
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grail intensified, and considerable effort was spent trying to answer the following 
basic question: 

Is there an adequately strong criterion for freedom from replay? 

In this section, we will report on some of the progresses that were made toward 
this elusive goal. We shall anticipate that this question is still open. As we will see 
in Section 5, this quest is not however as popular as it once was, mainly because 
several researchers have now given guidelines aimed at constructing protocols 
that are free from attacks by design. 

What Do We Mean by Entity Authentication? 

Gollmann raised the question in the title of this section in the homonymous 
paper [Gol96]. The notion of entity authentication had been used liberally, often 
abused, in the security literature (we gave one of the many definitions in Sec- 
tion 4.2). Gollmann’s paper discusses various meanings attributed to this phrase, 
and crystallizes some of these definitions in the context they ought to be used. 

One of the strongest meanings of “entity authentication” requires that all 
the communications that constitute a session be accessible only to the involved 
parties, or to some entity in whose integrity they can put a reasonable amount 
of confidence. This degree of authentication is usually attained by encrypting all 
the communications between two principals by means of a session key freshly 
generated in a secure manner by a trusted third party. This constitutes the 
essence of Gollmann’s first authentication goal: 

Gl: The protocol establishes a fresh session key, known only to the session 
parties and possibly to a trusted server. 

While this goal is sufficient when considering protocol runs in isolation, situa- 
tions that may involve several runs require reinforcing this requirement with the 
following clause: 

Gl’: Furthermore, compromising old sessions keys does not lead to the compro- 
mise of new session keys. 

In particular, new session keys should not be transmitted encrypted with old 
session keys. 

A second meaning of “entity authentication” requires that a principal A can 
ascertain that an interlocutor B has received and successfully interpreted a mes- 
sage sent by A to B. Gollmann expresses this requirement as follows, modulo 
minor editing: 

G2: A key associated with a principal B was used in a message received by 
another principal A in the protocol run, in a response to a challenge issued 
by A in the form of a nonce or a timestamp. 

This is what we called “entity authentication” in Section 4.2. 

A yet weaker form of “entity authentication” simply requires a principal to 
be able to ascertain that an intended interlocutor was active during a protocol 
run. This is expressed as the following goal: 
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G3: A key associated with a principal B was used during the protocol run, in 
a response to a challenge issued by another principal A in the form of a nonce 
or a timestamp. However, A did not need to receive a message where this 
key was used. 

This is essentially what we called “ping authentication” in Section 4.2. 



Agreements 

In [Low97], Lowe observed that all definitions used to talk about authenti- 
cation have the following form: 

A protocol V guarantees property X to initiator A for another princi- 
pal B, 

€ 

whenever A completes a run of the protocol, apparently with respon- 
der B, then a certain requirement '0 holds. 

We denote the condition “whenever A completes a run of the protocol, apparently 
with responder 5” as . Then, all the definitions can be seen as implications 
of the following form: 

Here, A and B are parameters rather than specific principals. Therefore, al- 
though these goals may appear to be bound to the principals, they are actually 
more general. 

It should be observed that these goals are validated once a run is completed. 
Therefore, they are intended to authenticate runs, rather than individual mes- 
sages as in the case of the requirements for BAN examined in Section 4.1. 

We will now examine some of the property-requirement pairs (A, ip) consid- 
ered in [Low97]. These definitions refine and give a more precise meaning to 
notions such as ping or entity authentications discussed above. 

Aliveness: ip = “H has been running the protocol” . 

This requirement extends ping authentication to protocol runs. When satis- 
fied, it guarantees that A’s interlocutor, B, has been active some time in the 
past. Situations in which the run proceeds smoothly from A’s point of view 
without B taking part in any action represent a failure of aliveness. We have 
observed such a situation in the attack to the BAN-Yahalom Protocol 5 in 
Section 4.3. 

Like every requirement discussed in [Low97], there is a recent version of 
aliveness: ip = “B has been running the protocol recently’’’ . Recent aliveness 
requires B to have been active during the current run. Notice that B does 
not need to have been running the same protocol as A, and even if he did 
he may have run it with a different party. 

It should be noted that recent aliveness is not only stronger than ping au- 
thentication, but it also subsumes VO’s entity authentication discussed in 
Section 4.2. Indeed, recent aliveness is manifested in a run of a cryptographic 
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protocol by witnessing precisely the transformations required by this form 
of authentication. From that point of view, recent aliveness possibly gives 
a meaning to the notion of entity authentication. 

Weak agreement: ip = “B has previously been running the protocol, appar- 
ently with A” . 

Weak agreement strengthens aliveness by requiring not only that A’s inter- 
locutor B was active, but that A had evidence that he participated in a very 
direct manner by decrypting or signing messages that he only could have 
processed (unless the relevant keys were compromised). Observe that weak 
agreement does not require B to be running the protocol with A, nor can it 
he assumed to don the expected role (e.g. if A acts as the initiator, B may 
not necessarily be playing the responder role). 

In [Low96, Low97], the difference between (recent) aliveness and weak agreement 
was illustrated by the attack below, which has achieved world fame and has 
become a major test bed, sometimes even a rite of passage, for every new protocol 
verification tool. Lowe’s attack operates on the following fragment of a protocol 
due to Needham and Schroeder [NS78], the public-key version of the Needham- 
Schroeder Shared-Key Protocol 1 analyzed in Section 2.3. 



Protocol 7 (Abridged Needham-Schroeder Public-Key) [NS78] 



Message 1 


A- 


^ B : 


{nA,A}kB 


Message 2 


B - 


A : 


{riA, nB}kA 


Message 3 


A- 


^ B : 





In this protocol, the initiator A sends her identity and a freshly generated 
nonce ha to B, protecting this message by encrypting it with i?’s public key ks- 
Upon receiving it, B generates a nonce of his own, ub, and sends it to A to- 
gether with Ha, encrypted with A’s public key. In the last message, A sends ub 
back to B, encoded with kB- The protocol originally described in [BAN89a] had 
an initial key distribution phase in which A and B requested and received the 
keys kA and kB from a trusted server. 

Upon completing a run of this protocol, A can be confident that she has been 
talking with B. Lowe’s attack [Low96] shows that this protocol does not provide 
the reverse assurance. The trace of this attack is as follows: 

1. A ^ E {uA,A}kE 

i. Ea^ B {uA,A}ks 
a. B ^ Ea {uB,nA}kA 

2. E ^ A {uB,nA}kA 

3. A ^ E {nB}kE 

in. Ea^ B {nB}kB 

On line (1), A starts the protocol with the intruder E, who accesses the contents 
of the first message, re-encrypts it with B’s public key and forwards it to this 
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principal in line (i). On line (ii), B replies as if the message had come directly 
from A. The attacker intercepts it and directs it to A in lines (ii) and (2). 
The initiator A completes the protocol with E by encrypting the nonce ub she 
received with public key. Finally, E forwards this nonce encrypted with ks 
to B. In the end, A (correctly) believes that she has been running the protocol 
with E, but B is fooled into assuming that he has been talking to A. 

It is clear that this attack proves that the Needham-Schroeder Public-Key 
protocol does not satisfy weak agreement from B's point of view (i.e. after swap- 
ping A and B in the above definition). However, it is proved in [Low97] that this 
protocol satisfies (recent) aliveness. 

This attack is routinely used in courses and lectures to support the idea that 
protocol analysis is difficult, and in seminars and papers to motivate new pro- 
posals in this area. It is indeed true that it revealed a novel vulnerability to 
a protocol published 18 years earlier, and proved correct by a number methods, 
most notably using the BAN logic [BAN89a]. However, the Needham-Schroeder 
Public-Key Protocol was never deployed in any real-life setting. More impor- 
tantly, a careful reading of [NS78] indicates that Lowe’s weak agreement for the 
responder was not among the goals of this protocol. 

Among the authors who challenged the legitimacy of this attack, Gollmann 
[GolOO] observed that it does not reveal any flaw if H’s objective in this pro- 
tocol was to have a communication with A. This corresponds to the notion of 
ping authentication (Gollmann calls it “authenticating packets”). However, if 
this protocol was used to establish a secure channel between the two parties, 
then Lowe’s attack is a clear manifestation of a violation. Gollmann called this 
situation “authenticating circuits” . 

Non-injective agreement (with respect to data set ds): ijj = “H has previ- 
ously been running the protocol, apparently with A, and B was acting as 
the responder in his run, and both agree on values of variables in ds^^ . 

A yet stronger form of authentication is given by non-injective agreement. 
Here, A’s interlocutor, B, is required to play the expected role, and their 
runs need to be synchronized to the extent that their respective variables 
among ds contain the same values. Observe however that this goal does not 
guaranteed a one-to-one relationship between A’s and B’s runs (hence the 
name) . 

The Needham-Schroeder Public-Key Protocol 7 does clearly not satisfy this 
requirement. There are however protocols that pass the weak agreement test, 
but fail non-injective agreement. Examples include the Andrew Secure RPG 
Handshake [Sat89, GJ97], and Snekkenes Protocol 6 analyzed in Section 4.3. 

Agreement: This goal, sometimes called injective agreement, reinforces non- 
injective agreement with the requirement that there is a one-to-one corre- 
spondence between runs. This last goal in [Low97] forces the runs of each 
involved party to by fully synchronized, and therefore may appear as the 
ultimate authentication requirement. 

The Wide-Mouthed Frog Protocol 4 presented in Section 4.1 can be proved 
to satisfy non-injective agreement, but does not pass the stronger agreement 
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test. An attack that exemplifies this situation is presented in [CJ97]; the 
adversary replays the server’s message to B within the lifetime of the times- 
tamp, essentially acquiring a new timestamp from the server, and repeats 
this game until A tries to run a legitimate session of the protocol with B, at 
which point he can replay the appropriate message to B. This attack can be 
formally expressed in a logic that includes time. A formal analysis in CSP 
using PVS is given in [ESOO]. 



Intensional Specification 

Lowe’s hierarchy of authentication goals discussed in the previous section 
was essentially a response to intentional specification, a perhaps overly strict 
notion of protocol correctness defined by Roscoe in [Ros96]. The definition of 
intentional specification is as follows: 

A party cannot believe that a run has completed successfully unless a 
series of messages that agree on all parameters has occurred, up to and 
including the last message communicated by the given party. 

In [Low97], Lowe observes that intensional specification is such a strong re- 
quirement that only the most inconsequential behaviors could violated it and 
yet satisfy agreement. Examples of such failures of intensional specification are: 

— Assume that, in response to a request, a server sends a pair of messages 

to principal A. This party can decrypt m,A, but not ms, and is 
expected to forward this component to another principal B, who is able to 
interpret it. We have seen an instance of this scenario in the BAN-Yahalom 
Protocol 5 discussed in Section 4.3. Lowe’s first example of an intensional 
specification “attack” that passes the agreement test relies on an adversary 
that substitutes tob with some random value X in the message from the 
server to A. Then, it reinstalls tob in place of X in the second message 
from A to B. 

— Lowe’s second “attack” example takes place in a situation where a server 
sends messages niA and ms to principals A and B, respectively, and in that 
precise order. An intruder delays the first message so that ms reaches B 
before niA reaches A. 

It has been debated whether these failures can reasonably be seen as attacks, 
in any even remotely practical meaning of the term. In particular, it is not 
clear whether there are “real” attacks that satisfy agreement but not intensional 
specification. These doubts are highlighted by analyzing the following previously 
unpublished protocol. 
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Protocol 8 (Unpublished) 



Message 1 


A- 


^ B : 


{uA: ^5 kAB 


Message 2 


B - 


-4 A : 


{ng,nA,A,B}kj,B 


Message 3 


A- 


^ C : 


{A,C, {n'A®ng)}k^c 


Message 4 


C- 


A : 


{nc, A, C, (n'^ 0 ns)}fc^c 


Message 5 


A- 


^ B : 


{ng,(n'J^^nc),A,S}kAB 



Principals A and B set up a mutual challenge involving nonces ua and ng in 
line (1) and (2). In line (3) and (4), a similar process occurs between A and C, 
but the fresh value in the third message is not properly a nonce, but the result 
of taking the X-OR of B’s nonce ng from line (2) and some newly generated 
nonce In the last message, A answers B’s challenge from line (2), but also 
includes one of these pseudo-nonces, which is obtained by taking the X-OR of C’s 
nonce nc and yet another nonce generated by A. 

Although we did not conduct a formal proof, this protocol seems to satisfy 
Lowe’s notion of agreement. There are however situations in which it violates 
Roscoe’s intentional specification: 

— Suppose that A sends the message in line (3) before receiving the nonce ng 

in line (2): she could for example use to form this message without 

taking any X-OR. While the one-to-one correspondence between runs is not 
affected, intensional specification is violated since C would receive the nonce 

rather than the pseudo-nonce (n'j^(Bng). This may be potentially harmful 
since the causal relation of messages appears to be affected. 

— Suppose now that A generates a nonce before receiving B’s nonce in 
line (2), waits for ng, and only then calculates = n’\ (B ng and sends 
the message in line (3). Now intensional specification seems to be satisfied. 
However, the end-result is identical since, being X-OR associative and idem- 
potent, {n\ 0 ng) 0 n_B = n\. Indeed, the value sent to C has been decided 
before receiving B’s message. 

— Last, consider an identical scenario, but in which A generates after receiv- 
ing B’s message in line (2), but without using ng. Now, the causal relation 
between the messages is clearly respected, yet C will receive a value that is 
independent from the nonce ng. 

Similar “attacks” can be constructed with respect the the messages on lines (4) 
and (5). 



Matching Histories 

Matching histories [DvOW92] is an older proposal whose strength fits be- 
tween Lowe’s (injective) agreement and weak agreement. This characterization 
of authentication is particularly interesting because its definition was developed 
by industrial specialists in secure system design and cryptography rather than 
by formal methods experts, as for the proposals discussed so far. In particular. 
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their focus was likely to be on a more practical articulation of the notion of 
“authentication” geared toward actual applications rather than on mapping out 
the theoretical terrain. 

A protocol satisfies matching histories if the following condition can be proved 
to hold: 

When a principal A accepts the other party’s identity (before receiving 
or sending further messages), the other party’s record of the partial or 
full run matches A’s (with the same values for all message variables). 

This requirement is as strong as Lowe’s (injective) agreement insofar as the 
number of runs and all variables must match between A and B. It is however not 
as powerful as weak agreement since B does not need to have been running the 
protocol with A. It can however be shown that matching histories and agreement 
are equivalent if every message exchanged in a protocol includes the identities 
of the apparent sender and of the intended recipient. 

It is interesting to observe that matching histories is motivationally similar 
to VO’s key confirmation (see Section 4.2), 

P believes {P ^ — > Q A Q says F{k)) 

while Lowe’s various “agreements” goals are motivationally similar to VO’s mu- 
tual understanding of shared keys (see Section 4.2) and to BAN’s second-order 
belief (see Section 4.1), 

P believes Q says {Q — > P) P believes Q believes {Q P). 



Cautionary Note 

By the end of the 1990s, the research on issues related to authentication had 
proliferated to the point that some practitioners started noticing a dichotomy 
between the problems addressed in the academic literature on security, and the 
solutions sought in real world scenarios. Gollmann, again, voiced these concerns 
in the paper [GolOO] . He observed that the research in this area was often fueled 
by a perceived informality in protocol analysis, and, putting it in his own words, 

[this] motivates the presentation of a new formalism for the analysis of 
authentication protocols, and the biggest prize to be won is the detection 
of an attack hitherto unreported. We will argue that such exercises in 
formal analysis more often add to the problem than help in its resolution. 

Furthermore: 

Perceived problems with authentication are caused by intuitive but impre- 
cise interpretations of the objective of “authentication” , and by neglecting 
to take into account the environment a protocol is intended to operate in. 

In many cases, new attacks do not expose subtle flaws in protocols but 
differences in assumption about protocol goals. 
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However, sometimes they do expose subtle flaws. Furthermore, new theories 
sometimes do turn out to be practically useful. Clearly, this is not always the 
case, but even then, they often have an impact on our understanding of the 
various concepts that contribute to what we call security. In these cases (and 
many other), it is essential not to mistake theoretical results for applied ones, or 
vice versa. 

5 Design Principles and Protocol Logics 

At this point we take a brief holiday from formal characterizations of authenti- 
cation to consider protocols from a more informal and more applied perspective. 

5.1 Protocol Design Principles 

Abadi and Needham set out “prudent engineering practices for cryptographic 
protocols” in [AN94, AN96]. These are rules of thumb for good protocol design. 
They are not meant to apply to every protocol in every instance, but they 
do provide a laundry list of things that should be considered when designing 
a protocol. The paper contains useful examples and discussion of the principles. 
We quote from [AN96] just the principles here and then briefly comment on 
them below. 

Principle 1. Every message should say what it means: The interpretation of 
the message should depend only on its content. It should be possible to write 
down a straightforward English sentence describing the content — though if 
there is a suitable formalism available, that is good too. 

Principle 2. The conditions for a message to be acted upon should be clearly 
set out so that someone reviewing the design may see whether they are ac- 
ceptable or not. 

Principle 3. If the identity of a principal is essential to the meaning of a mes- 
sage, it is prudent to mention the principal’s name explicitly in the message. 
Principle 4. Be clear as to why encryption is being done. Encryption is not 
wholly cheap, and not asking precisely why it is being done can lead to 
redundancy. Encryption is not synonymous with security, and its improper 
use can lead to errors. 

Principle 5. When a principal signs material that has already been encrypted, 
it should not be inferred that the principal knows the content of the message. 
On the other hand, it is proper to infer that the principal that signs a message 
and then encrypts it for privacy knows the content of the message. 
Principle 6. Be clear about what properties you are assuming about nonces. 
What may do for ensuring temporal succession may not do for ensuring 
association — and perhaps association is best established by other means. 
Principle 7. The use of a predictable quantity (such as the value of a counter) 
can serve in guaranteeing newness, through a challenge-response exchange. 
But if a predictable quantity is to be effective, it should be protected so that 
an intruder cannot simulate a challenge and later replay a response. 
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Principle 8. If timestamps are used as freshness guarantees by reference to 
absolute time, then the difference between local clocks at various machines 
must be much less than the allowable age of a message deemed to be valid. 
Furthermore, the time maintenance mechanism everywhere becomes part of 
the trusted computing base. 

Principle 9. A key may have been used recently, for example to encrypt 
a nonce, yet be quite old, and possibly compromised. Recent use does not 
make the key look any better than it would otherwise. 

Principle 10. If an encoding is used to present the meaning of a message, then 
it should be possible to tell which encoding is being used. In the common case 
where the encoding is protocol dependent, it should be possible to deduce 
that the message belongs to this protocol, and in fact to a particular run of 
the protocol, and to know its number in the protocol. 

Principle 11. The protocol designer should know which trust relations his 
protocol depends on, and why the dependence is necessary. The reasons for 
particular trust relations being acceptable should be explicit though they will 
be founded on judgment and policy rather than on logic. 

5.2 Design Principle Comments 

Such rules of thumb should always be considered when designing a protocol and 
only violated when the violation is consciously done for a superseding reason. 
Since the rules are generally quite compelling, we focus on some of the ways 
in which they might not apply, as a caution against applying them blindly. 
(Comments in this section are mostly drawn from [Syv96].) 

Building on the above principles, Anderson and Needham set out further 
principles specifically focused on public-key protocols. Their first principle is an 
expansion of Principle 5 above. 

Sign before encrypting. If a signature is affixed to encrypted data, then 
one cannot assume that the signer has any knowledge of the data. A third 
party certainly cannot assume that the signature is authentic, so non- 
repudiation^ is lost. ([AN95], p. 237, Principle 1) 

This is a nice principle for illustrating limitations: there are many places 
where non-repudiation may not be of paramount concern; thus the principle may 
be too narrow. For example, anonymity may take priority over non-repudiation. 
This would occur in voting protocols, and in digital cash. Digital cash often 
makes use of a blind signature, in which the authority issuing the cash signs 
a ‘coin’ that has been ‘blinded’ so that the authority cannot recognize the specific 
coin and thus tie it to the principal to whom it was issued. After signing the 
blinded coin, the principal unblinds it so that anyone can recognize it as a coin 
authentically signed by the issuer.® 

^ The goal of non-repudiation is to prevent a principal from denying some action s/he 
has taken, such as sending or receiving a message. 

® This is a very simple description. Blinding was invented by Chaum [Cha83]. More 
on digital cash and other applications of blinding can be found in [Sch96]. 
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This principle may also be too broad: signing encrypted data may be neces- 
sary for non-repudiation. One place this can be seen is in a coin-flip protocol. 
A principal signs encryptions of “Heads” and “Tails” and later reveals the en- 
cryption key. Part of the reason is so that she cannot deny the choices offered 
and also so that the opposing principal cannot deny the choice made. A simple 
coin-flip protocol protocol demonstrating this point was given in [Syv96] . What 
follows is an even more simple version of this (without, e.g., replay protection). 
Other similar protocols were discussed in [Tou92]. 



Protocol 9 (Simple Coin Flip) 



Message 1 


A- 


^ B : 


'l{Heads)k, {Tails) k\k~^ 


Message 2 


B 


-4 A : 


\_X\^-i (where X is one of {Heads} k or {Tails} k) 


Message 3 


A- 


^ B : 


7^ 


Message 4 


B - 


A : 





Non-repudiation is a fairly subtle requirement. It may be unsurprising that 
principles such as the one under discussion are subject to the cautionary remarks 
we have been making. Explicitness, however, would seem to be paramount in all 
security protocols, and especially in authentication protocols. Indeed, Abadi and 
Needham regard it (as embodied in Principles I and 2 above) as the overarching 
principle in the design of secure cryptographic protocols. It is therefore surprising 
that there are authenticated key distribution protocols that can only function in 
the absence of explicitness (especially explicitness as in Principle 10). We now 
present such a protocol. 



Protocol 10 


(EKE 


- Encrypted Key Exchange) [BM92, BM93] 


Message 1 


A- 


^ B : 


A, {kA}p 


Message 2 


B - 


A : 


{{kAB}kA)p 


Message 3 


A- 


^ B : 


{’^a} kAB 


Message 4 


B - 


-4 A : 


'^b\ kAB 


Message 5 


A- 


^ B : 


{'^B}kAB 



The idea of the EKE protocol is to function as a privacy multiplier. Let Alice 
be some client and Bob a server for which Alice has password P. P is thus a secret 
shared between A and B, and the only means of authentication A possesses. She 
encrypts a public key with P and sends it to Bob. Bob generates a session 
key kAB and encrypts this with Ua and then encrypts the result with P. There is 
then a handshake that shows fresh possession of the session key. The important 
thing to observe about this protocol is that the content of messages cannot be 
confirmed upon receipt since the recipient of a message cannot tie its content 
to any known values until s/he completes the protocol. In particular, principals 
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cannot tell if received messages have the correct form for them to take the 
next step. It is only when a recipient gets his last message that he can confirm 
that the preceding messages had the correct content and acting upon them was 
appropriate. If any of the messages contained adequate redundancy in content 
or coding for a principal to know what s/he is receiving (or sending) before the 
end of the protocol, then the protocol would be vulnerable to guessing attacks 
since P is a weak secret. 

Even if this protocol is a counterexample to the complete generality of ex- 
plicitness, it is also an example for another of the design principles; Anderson 
and Needham warn 

Be careful when signing or decrypting data that you never let yourself 
be used as an oracle by your opponent. ([AN95], p. 240, Principle 3) 

EKE puts a spin on that principle; instead of preventing use of principals as 
oracles it ensures that the output of such oracles is of no use to the attacker. 

Despite such unusual examples, explicitness is very often exactly what is 
required. We now delve deeper into its implications. 

5.3 Fail-Stop Protocols 

For any definition of authentication, almost all of the failures in the literature are 
due to active attacks in which a message is somehow altered or substituted for 
another in a way it was not intended. Thus, stopping such attacks would go a long 
way towards a general guarantee of protocol security. Fail-stop protocols [GS98] 
are designed to meet this goal. 

Using Lamport’s definition of causality [Lam78], we can organize the mes- 
sages of a protocol into an acyclic directed graph where each arc represents 
a message and each directed path represents a sequence of messages. In a fail- 
stop protocol, if a message actually sent is in any way inconsistent with the 
protocol specification, then all those messages that come after this altered mes- 
sage on some path in the graph (i.e., they are causally after the altered message) 
will not be sent. Obviously conditions to act upon all protocol messages must 
be explicit in the content and format of each message in order for the protocol 
to be fail-stop. 

A protocol is said to be fail-stop if any attack interfering with a message in 
one step will cause all causally-after message in the next step or later not to be 
sent [GS98]. 

No definition of authentication given so far is sufficient for fail-stop. The 
main reason is that the definitions we have discussed are focussed on properties 
that must hold if and when a principal has completed a protocol run. But, fail- 
stop is a requirement that must hold as the protocol executes. For example, 
consider the EKE protocol of the last section. This is quintessentially not fail- 
stop. A principal cannot confirm anything about the content or possibly even 
encoding of any message until s/he has received the last message of the protocol 



run. 
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Claim 1 Active attacks cannot cause the release of seerets within the run of a 
fail-stop protocol. 

Claim 1 follows immediately from the definition of a fail-stop protocol, be- 
cause active attacks do not cause more (or different) messages to be sent; so an 
attacker using active attacks cannot obtain more secrets than one using passive 
eavesdropping. 

One of the desirable features of a fail-stop protocol is this form of immunity 
to active attacks. More generally, since an active attack will cause a fail-stop pro- 
tocol to halt, in a fail-stop protocol no principal will ever produce encryptions 
or any other computations on data from a message that was not entirely legiti- 
mate. Therefore, we need to consider only passive attacks in which an adversary 
records messages and tries to compute secrets from them. Such passive attacks 
(and protection measures against them) are much better understood than active 
attacks and easier to analyze. And, as already noted, they are substantially less 
common in the attack literature. 

This shows us the beginnings of a synergy between design principles and 
formal analysis, except that fail-stop is not quite a design principle. But the 
synergy can be strengthened via explicitness based on the principles of Abadi 
and Needham. 

One of the ways to make a protocol fail-stop is to design it in accordance 
with the following criteria: 

1. The content of each message has a header containing the identity of its 
sender, the identity of its intended recipient, the protocol identifier and its 
version number, a message sequence number, and a freshness identifier. 

2. Each message is encrypted under a key shared between its sender and in- 
tended recipient. 

3. An honest principal follows the protocol and ignores all unexpected messages. 

4. A principal halts any protocol run in which an expected message does not 
arrive within a specified timeout period. 

Here a freshness identifier can be a timestamp (if clocks are assumed to be 
securely and reliably synchronized) or a nonce issued by the intended recipient. 
But, the freshness identifier in the first message of the protocol cannot be a nonce 
since the recipient must be able to determine if the protocol should proceed 
based on it. So, it must be a sequence number, timestamp, or something that 
will meaningfully indicate freshness to the recipient. When a freshness identifier 
takes on a more complicated form, the rules for reasoning about freshness in 
sections 2 and 3 can be used to determine if the identifier is fresh with regard to 
the recipient. Basically, these rules say that, if x is deemed fresh and y cannot be 
computed (in a computationally feasible way) by someone without the knowledge 
of x, then y is also deemed fresh. Encryption with a shared key in item 2 of this 
claim can be replaced by the use of an encryption using the recipient’s public 
key of a signature using the sender’s private key. We can offer no formal proof 
of the claim, but it should be clear by inspection. 
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It might seem that fail-stop protocols automatically guarantee authentica- 
tion. 



Protocol 11 (Simple Fail-Stop Example) 

Message 1 A ^ B : {A, B, Protjname, version, seq.= 1, Ta, Query}kj^s 
Message 2 B —f A : Response. 



In the first message Ta is a timestamp, and other fields have their obvious 
meaning. This message clearly follows the format of above design criteria. The 
second message is not of that format, but since it is the last one in the protocol, 
there are no causally-after messages. Thus, the protocol is fail-stop. However, 
the second message is not authenticated (according to virtually any definition). 

Extensible Fail- Stop Protocols 

A protocol can be fail-stop even if it contains messages that could have come 
from any principal at any time. In this section we explore a strengthening of the 
fail-stop concept. 

A message in a protocol is last if no protocol message is causally after it. 
A protocol is extensible fail-stop (EFS) if adding any last message to the protocol 
results in a fail-stop protocol. 

Note that limiting to ’’ping-pong” protocols (where each message is followed 
by a single successor) implies a unique last message. This is the typical case 
for two party authentication protocols. The example of Protocol 11 is not EFS 
because adding a another message after Message 2 would result in a protocol 
that is not fail-stop. For EFS protocols, authentication is in fact automatically 
guaranteed — but only message authentication. An example of an EFS protocol 
is as follows: 



Protocol 12 (Simple EFS Example) 


Message 1 A — > S' 


{A, S, Prot., vers., seq.= 1, Tx, request{A,B)}]^^g 


Message 2 S ^ A 


{S, A, Prot, vers., seq.= 2, T 2 , {k,A,B)}kj,s 


Message 3 A — > S 


{A, S, Prot, vers., seq.= 3, Ts, {k,A,B)}kAs 


Message 4 S ^ B 


{S, B, Prot, vers., seq.= A, T 4 , {k,B)}kBs 


Message 5 B ^ S 


{B, S, Prot., vers., seq.= 5, T 5 , {k,B)}kBs 



This example demonstrates that fail-stop, even extensible-fail-stop, does not 
imply that the protocol satisfies all kinds of authentication. In the example, all 
messages are authenticated, but Bob does not know with whom he shares a key. 
Even a protocol in which Bob is given the wrong name for the principal meant 
to share the key could still be EFS. 

Roughly, most of the authentication properties discussed in Section 4 are 
properties established by a complete protocol run about messages and the con- 
tent of messages sent during that run. But, (extensible) fail-stop properties are 
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authentication properties established by messages about the complete protocol 
run. For example, the following claim is immediate. 

Claim 2 Extensible fail-stop protocols are immune to replay. 

There is another, potentially more interesting property of EFS protocols. 

Claim 3 The sequential and parallel composition of EFS protocols is extensible 
fail-stop. 

The claim is justified by cases. For parallel composition: a message inserted 
causally before a last message of a fail-stop protocol will be ignored or cause a 
halt. Thus, it will not cause an EFS protocol to cease to be EFS. For sequential 
composition: let Pri and Pr 2 be two EFS protocols. Suppose that some or all of 
the messages of Pr\ are received after a last message of PR 2 . If the first message 
of Pri causes the result to be non-EFS, then Pr 2 was not EFS. (Contradiction.) 
And, if any later message causes the result to be non-EFS, then Pri was not 
EFS. 

We have already seen that fail-stop protocols need only to be examined for 
secrecy in the context of passive attacks (because active attacks cannot cause the 
release of secrets). In addition to its inherent interest. Claim 3 provides another 
design advantage of EFS protocols. Even analyses that consider interleaving 
typically assume only one protocol is running. If protocols are EFS, we are free 
to run multiple protocols in one environment without concern for interleaving 
attacks.® 

As noted above, EFS protocols can be simply designed using basic explicit- 
ness rules. EFS protocols more flexible wrt composability, and EFS rules simplify 
the analysis task by removing replay considerations. How else might design rules 
synergize with protocol analysis logics? 

5.4 Design Rules and Protocol Logics 

A straightforward way for design rules to synergize with protocol logics is 
to build design checks directly into the logic. Brackin did precisely that 
in [BraOO]: he designed the logic BGNY [Bra96], based on GNY. He later de- 
veloped an associated automated HOL tool, AAPA (Automated Authentica- 
tion Protocol Analyzer) [Bra98], and a specification language similar to Milieu’s 
GAPSL [DM00, Mil]. The resulting system appears to be easy to use. Brackin 
has analyzed the entire Glark-Jacob library^® using AAPA. He has also ana- 
lyzed large commercial protocols such as the Gybercash main sequence proto- 
col [Bra97]. This alone makes his a significant body of work, although we are 
not primarily concerned with automated tools in this paper. 

® See Section 7 for a cautionary note. 

The Clark-Jacob library is a fairly comprehensive list of known attacks on published 
authentication protocols [C.J97]. 
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Wedel and Kessler devised another BAN logic we will call ‘WK’ [WK96]. WK 
works with an automated tool AUTLOG based on Prolog. One advantages of 
the WK approach is that no formulae occur in messages. This is another step in 
solving the problem of the informal nature of idealization. Of course there is still 
the need for interpretation assumptions (as they were called in Section 3.4). That 
part cannot be automated. However, analysis in WK automates derivation of the 
comprehension assumptions. Recall that these were the assumptions that allowed 
us to express what a principal understands of received messages even though 
some of the message may be unfamiliar or not decryptable by the principal. In 
fact, the WK notation for not-understood messages motivated the notation given 
above in Section 3, although the use by Wedel and Kessler is not exactly the 
same. Another automated tool in the BAN family is the recent C3PO of Anthony 
Dekker [DekOO]. This is a GUI tool based on the Isabelle theorem-prover. The 
logic associated with this tool is called ‘SVD’, and, like WK, it is a variant on 
SVO. Neither of these has the published track record of analyses of Brackin’s 
work, however. 

A different approach to automation that again combines logics and design 
is that taken by Glark and Jacob in [CJOO]. In some sense the idea of this 
approach is to not do design at all. Rather goals are stated and then protocols 
are synthesized that meet these goals. Glark and Jacob automatically generate 
protocols from basic BAN logic goals (as described in Section 4.1) using genetic 
algorithms and simulated annealing. Another automated synthesis, but based on 
Song’s Athena model checker rather than on BAN, was presented by Perrig and 
Song in [PSOO]. Related ideas can be found in [Gut]. This no-design approach 
may have great long term potential, but it is still early. As we have seen, even 
simple protocols are subtle and the contribution of such approaches may be 
to produce protocols with desirable features that no person would be likely to 
design. 

Buttyan, Staamann, and Wilhelm also synthesize protocols from a BAN-like 
logic [BSW98]. However, unlike the previously mentioned approaches that effec- 
tively generate random protocols and then prune to the results that meet desired 
goals, they directly synthesize protocol designs from goals. Their protocol de- 
signs are slightly more abstract than we have been considering. They specify 
and reason about protocols on the more abstract level of channels. The encryp- 
tion mechanism used to secure the channel is regarded as an implementation 
issue. The result is thus somewhat similar to spi calculus [AG99] but is closer 
to Needham-Schroeder style specifications. Roughly speaking, their design logic 
synthesis rules work by running an abstracted version of BAN in reverse. For 
example, if C is a channel, then the following is a synthesis rule. 

P believes P received X on C 
P sees X on C P can read C 

A protocol that would satisfy the goal above the line would need to have P re- 
ceiving X on channel C, where C might be, e.g., encryption using P’s public 
key or a key P shares with another principal. 
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These rules give articulated goals, not conclusions. In some cases they yield 
intermediate goals that require further applications of rules before the protocol 
can be synthesized. 

A common theme of this design logic and the synthesis tools is that one 
first specifies what is wanted then looks at the protocol. That means that one 
must state generic requirements in a formal language. The intuitive expression 
of requirements is thus a strong advantage of the logical approach. This also 
suggests another way of combining formal requirements statements with existing 
formal analysis techniques: Give the semantics of requirements language in the 
language of the formal analysis method. Then, use the formal analysis method 
to evaluate the truth of requirements statements in models of the protocol. 

6 Semantic Approaches 

We have seen in the previous section that it is often advantageous to use distinct 
languages to express a protocol under investigation and the goals it is expected 
to meet. The protocol specification language typically has an operational flavor 
that makes it particularly adequate for analyses based on simulation, such as 
model checking. Requirements are more easily stated in declarative formalisms, 
preferably with strong logical foundations. In order to be usable, requirements 
need to be mapped down to the execution model supported by the protocol 
specification language. We do so by endowing the requirement logic with an 
operational semantics in terms of the formalism used to express the protocol. 

In this section, we will briefly examine two instances of this symbiosis. First, 
in Section 6.1, we look at the successful NRL Protocol Analyzer [Mea94, Mea96] 
together with the NPATRL requirements logic [SM96]. Then, in Section 6.2, 
we discuss a recently proposed synergy that adopts the popular strand formal- 
ism [THG97, THG98b] as an operational model and a BAN-like logic as the 
specification formalism [SyvOO] . 

6.1 NPATRL 

Our first case study will consist of the established synergy between the NRL Pro- 
tocol Analyzer [Mea94, Mea96] and the NPATRL requirement language [SM96]. 
We first sketch relevant aspects of the NRL Protocol Analyzer and then intro- 
duce NPATRL. 



The NRL Protocol Analyzer Model 

The NRL Protocol Analyzer, or NPA for short, is a computer-assisted verifi- 
cation tool for security protocols which combines model checking and theorem- 
proving techniques to establish authentication and secrecy properties. We will 
limit the presentation of this system to the aspects that will be relevant to our 
discussion of the NPATRL language. The interested reader is invited to con- 
sult [Mea94, Mea96] for further details. 
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A protocol is modeled as a number of communicating state machines, each 
associated with a different roles. Their transitions correspond to the actions 
that comprise the corresponding role. At run time, roles are executed by honest 
principals who faithfully follow the protocol. Several instances can be executing 
at the same time, and they are distinguished by means of a unique round number. 

The intruder is modeled after the Dolev-Yao adversary, described in Sec- 
tion 1.1. Dishonest principals share their keys and other confidential information 
with the adversary. 

The messages in transit, the information held by each principal and the 
intruder, the runs currently being executed, and the point that each of them has 
reached constitute the global state of the NRL Protocol Analyzer. A protocol 
action implements a local transformation with global effects on the state. The 
initial state is implicit in the protocol specification. 

In order to verify a protocol, a specification is fed into the run-time sys- 
tem of the NRL Protocol Analyzer together with the description of a family of 
states that correspond to attack situations. The system applies protocol actions 
backwards from these target states until it either reaches the initial state, or it 
exhausts all possibilities for doing so. In the first case, it reports the sequence of 
transitions that link these two states: this tracks a possible attack. The second 
case establishes that an attacker cannot produce the target scenario. Although 
the search space is in general infinite, the NRL Protocol Analyzer incorporates 
techniques based on theorem proving that have the effect of soundly restricting 
the search to a finite abstraction, in most cases. We can pictorially describe the 
operations of the NRL Protocol Analyzer by means of the following diagram, 
where we have kept the fairly stable intruder model implicit: 



Family of 

undesirable final states 

i 



NPA protocol 
specification 



NPA checker 



OK / Attack 



As it regresses back towards the initial state, the NRL Protocol Analyzer 
maintains a trace of the sequence of actions that, when executed, lead to the 
target state. If the initial state is ever reached, the sequence constructed in this 
manner is returned as a description of the attack it has found. When a path is 
abandoned, the corresponding trace fragment is discarded. Traces are sequences 
of events of the following form: 

event{P, Q, T, L, N) 

In general, any protocol or intruder state transition may be assigned an event. 
The arguments are interpreted as follows: P is the principal executing the tran- 
sition, Q is the set of the other parties involved in it, T is a name that identifies 
the transition, L is a set of relevant words, and N is the local round number of 
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the transition. There are three categories of events which correspond to receiving 
a message (predicate “receive”), accepting data as valid as a result of performing 
certain checks (predicate “accept”), and sending a message (predicate “send”). 
Here are two examples: 

accept(user(A, honest), [user(H, H)], initiator _accept_key, [K],N) 
send(server, [user(H, honest), user (H, honest)], server^end_key, [K],N) 

The first event describes the execution of a transition called “initiator_ac- 
cept-key” by honest principal A that involves a key K and some other principal B 
who may or may not be honest. The second event records a server’s application 
of rule “server^end_key” relative to honest principals A and B, and key K. 

Any principal can perform a “send” or a “receive” event, but only the honest 
principals are entitled to do an “accept” event. As we will see below, events are 
the building blocks of the NPATRL language. 



A Requirement Language for the NRL Protocol Analyzer 

The NRL Protocol Analyzer model described above has successfully been 
used to verify a number of protocols, sometimes uncovering previously unknown 
flaws [Mea94, Mea96]. This is all the more laudable once we acknowledge the 
implicit and rudimentary manner in which requirements are entered in this sys- 
tem: secrecy and authentication goals are expressed as states that should not be 
reachable from the initial state. This unintuitive and occasionally error prone 
way of writing requirements would have made it very difficult to use the NRL 
Protocol Analyzer for large protocols. 

The NRL Protocol Analyzer Temporal Requirements Language, better known 
as NPATRL (and pronounced “N Patrol”), was designed to address these short- 
comings [SM96]. This formalism makes available the abstract expressiveness of a 
logical language to specify requirements at a high enough level to capture intu- 
itive goals precisely, and yet it can be interpreted in the NRL Protocol Analyzer 
search engine. 

NPATRL requirements are logical expressions whose atomic formulas are 
event statements: they include the “receive”, “accept” and “send” events that 
can be found in the trace of an NRL Protocol Analyzer search, and the special 
“learn” event that indicates the acquisition of information by the adversary. The 
logical infrastructure of NPATRL consists of the usual connectives A, etc, 
and the temporal modality <$■ which, similarly to what we saw in Section 4.3, is 
interpreted as “happens before” or “previously” . 

For example, we may have the following requirement: 

If an honest principal A accepts a key K for communicating with another 
honest principal B, then a server must have previously generated and 
sent this key with the idea that it should be used for communications 
between A and B, and that both are expected to be honest. 
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We can use the NRL Protocol Analyzer events given in the previous section to 
construct an NPATRL formula that expresses it: 

accept(user(A, honest), [user(R, 77)], initiator _accept_key, [K],N) 

— > <8” send(server, [user(A, honest) , user(7?, honest)] , server _send_key, [K],N) 

This formula is a simple expression of the above requirement. A direct encoding 
in terms of final states is tricky, in particular if we want to faithfully express the 
temporal meaning of the operator “O” . 

Intuitively, the protocol verification process changes from what we discussed 
in the previous section by using NPATRL requirements where the final state 
appeared. More precisely, we first need to map every NPATRL event statement to 
an actual event in the NRL Protocol Analyzer specification of the protocol. Then, 
we take the negation of each NPATRL requirement as a way to characterize the 
states that should be unreachable if and only if that requirement is satisfied. 
At this point, we perform the analysis as in the previous section: if the NRL 
Protocol Analyzer proves that this goal is unreachable, the protocol satisfies the 
original requirement. Otherwise, it returns a trace corresponding to a attack on 
the protocol that potentially invalidates the requirement. 

Abstractly, the verification process of the NRL Protocol Analyzer enhanced 
with the NPATRL language can be expressed by the following diagram: 



Negated 

NPATRL requirements 

i 



NPA protocol 
specification 



NPA checker 



OK / Attack 



NPATRL has been extensively used in the last few years to analyze proto- 
cols with various characteristics. Among these, generic requirements have been 
given for two-party key distribution protocols [SM93, SM94] and two-party key 
agreement protocols [SM96]. The most ambitious specification undertaken using 
NPATRL has involved the requirements of the credit card payment transaction 
protocol SET (Secure Electronic Transactions) [MS98]. SET proved particularly 
difficult to specify for several reasons. First, nowhere in its hefty documentation 
(indeed, about 50cm thick) [SET97] are the requirements of this protocol stated, 
even informally. Second, it relies on some unfamiliar constructs such as dual sig- 
natures. Finally, the objects to be authenticated are dynamic: unlike keys, what 
is agreed upon changes as it passes from one principal to another. This exercise 
revealed several ambiguities [MS98]. 

6.2 Strand Semantics for BAN Languages 

In the last section, we presented a case study that separated the syntax in 
which requirements are best stated (NPATRL) from the semantics in which the 
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protocol is best specified and evaluated (NPA). In this section we explore the 
possibility of a similar strategy for BAN-style languages. (The content of this 
section is largely taken from [SyvOO].) 

Some BAN-like logics already have a model-theoretic semantics, for example, 
AT and SVO. Such a semantics can provide assurance in the reasoning embodied 
in a logic, via a soundness result. However, as illustrated in the last section, it can 
also provide another level on which to reason. These points were alluded to in 
Sections 2.4 and 3.5. And, providing an independently motivated model-theoretic 
semantics for BAN was a central design idea underlying the development of 
both AT and SVO. But, the model of computation in the semantics for each 
of these was adapted from general models underlying epistemic logics to reason 
about distributed computing. Their primary focus was not authentication or 
even cryptographic protocols generally. It is perhaps not surprising, therefore, 
that previous analysis showed AT and SVO computational models not easily 
compatible with those of NPA [Mea94, Syv98]. 

Perhaps what is needed is a model of computation that is more directly 
intended to represent authentication protocols. One such model is strand spaces 
[THG97, THG98b]. (See also [Gut] in this volume. Related to strands is the 
multiset rewriting (MSR) approach [GDL+].) Besides being a model specifically 
directed at this problem area and having a growing base of theoretical literature, 
it seems to fit somewhat naturally to NPA and similar tools, e.g., Athena [Son99]. 
The question that naturally arises is then whether we can effectively repeat the 
above NPATRL idea using something like BAN for the requirements language 
and strands as the model. In other words, could we have a process as expressed 
in the following diagram? 



BAN-style authentication goals 

i 

Strand protocol 
specification 



An affirmative answer would require a strand semantics for a BAN-style 
language. We will present a proposal for one below. We shall first provide a brief 
overview of the relevant strand space concepts. 



Strand machine 



OK / Attack 



Overview of Strands 

A strand is basically a local history of sent and received messages in a protocol 
run. A strand space is a collection of strands, and a bundle is a graph that reflects 
a causally meaningful way that a set of strands might be connected. 

The messages sent between principals are taken from an algebra A of terms. 
We will say more about the algebra shortly. Terms can be signed, e.g., -l-t or —t, 
to indicate sending and receiving of messages respectively. We will give defini- 
tions for all the relevant concepts below. First, here is a picture of a bundle for 
Protocol 7, the (abridged) Needham-Schroeder Public-Key Protocol. 
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+{riA, A}ks 



— {UA, riB}kA 



~{nA,A}ks 



+{nA,riB}kA 



+{«s}fcB 

The vertical sequences of double arrows are the strands, the local traces of 
messages sent to and from a given principal (in a given run). The horizontal 
(single) arrows link one strand to another by connecting the transmission and 
the reception of the same message. We now give more precise definitions, all of 
which are taken from [THG99b]. 

Let S he a set of strands and (±A)* be the set of all finite sequences of 
signed terms. A strand space over A is a set U together with a trace mapping 
tr:E^ (±A)*. 

Fix a strand space E 

1. A node is a pair (s,i), with s £ E and i an integer satisying 1 < i < 
length(tr(s)). The set of nodes is denoted by N. We will say the node (s,i) 
belongs to the strand s. Clearly, every node belongs to a unique strand. 

2. If n = (s, i) € Af then index(n) = i and strand(n) = s. Define term(n) to be 
(tr(s))^, i.e. the ith signed term in the trace of s. Similarly, uns_term(n) is 
((tr(s))j)2, be. the unsigned part of the ith signed term in the trace of s. 

3. There is an edge rii ^ ri2 if and only if term(ni) = +a and term(n2) = —a 
for some a £ A. Intuitively, the edge means that node rq sends the message a, 
which is received by U2, recording a potential causal link between those 
strands. 

4. When ni = (s, i) and ri2 = (s,*+l) are members of Af, there is an edge n\ =^ri2- 
Intuitively, the edge expresses that rii is an immediate causal predecessor 
of ri2 on the strand s. We write n' =^“'" n to mean that n' precedes n (not 
necessarily immediately) on the same strand. 

5. Af together with both sets of edges rii — > ri2 and ni U2 is a directed graph 
(Af,(-U^)). 

Suppose -^c C suppose =>c ^ =^; and suppose C = {~^C U =>c)) is 

a subgraph of {J\f, U =>)). C is a bundle if: 

1. C is finite. 

2. If ri2 G A/c and term(ri2) is negative, then there is a unique ni G Afc such 
that ni — i-c ri2- 

3. If ri2 G Afc and ni ri2 then ni ri2- 

4. C is acyclic. 

If 5 is a set of edges, i.e. S C (— > U =^), then is the transitive closure 
of S, and ^5 is the reflexive and transitive closure of S. The relations As and 
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are each subsets of A /5 x A/ 5 , where A /5 is the set of nodes incident with any 
edge in S. 

These are all of the definitions that we need to set out a possible worlds model 
and semantics for sending, receiving, and knowledge. We will provide below more 
details about the term algebra that will allow us to express, e.g., that a principal 
who receives a ciphertext (encrypted message) and has the decryption key has 
also got the unencrypted message. 



Possible Worlds from Strand Spaces 

We now describe a possible world semantics of epistemic logics for distributed 
computing in general and for security protocols in particular, for example, as 
presented in [AT91, Sv094, Sv096]. 

In a traditional system model and knowledge semantics for distributed com- 
puting, computation is performed by a finite set of principals. Pi, . . . , who 
send messages to one another. In addition there is a principal Pg representing the 
environment. This allows modeling of any penetrator actions as well as reflecting 
messages in transit. 

Each principal Pi has a local state Si. A global state is thus an (n -I- l)-tuple 
of local states. 

A run is a sequence of global states indexed by integers to represent time. 
The first state of a given run r is assigned a time tr < 0. The initial state of the 
current authentication is at t = 0. The global state at time t in run r determines 
a possible world (sometimes also called nodes or points) . We assume that global 
states are unique wrt runs and times. Thus, they can be referred to by, e.g., 
‘(r, t)' . At any given global state, various things will be true, e.g., that principal Q 
has previously sent the message {X}k- What a principal P then knows (believes) 
at a given point (r, t) is precisely that which is true at all possible worlds with 
the same local state rp{t) for P as (r, t). This is typically captured by means 
of an accessibility relation on global states '^p for a principal P. When the 
relation is an equivalence, it is also called an indistinguishability relation ~p for 
a principal P. This allows for a simple intuitive definition, without even having 
to describe in any way properties of local states, viz: 

— (r, t) ~p {r' ,t') iff P is in the same local state at both points, i.e., rp{t) = 

r'p{t'). 

Given an indistinguishability relation, we can then go on to define princi- 
pal P’s knowledge in terms of the worlds that are P-indistinguishable. 

— (r, t) 1= P knows ip iff \= ip for all (r',f') such that (r, f) ~p {r' ,t') 

The above system model and characterization of knowledge (belief) is es- 
sentially what is found in [AT91, Sv094, Sv096]. It is largely based on similar 
models and characterizations of knowledge in distributed computing; see for ex- 
ample [FHMV95]. Note that the relation just given is an equivalence relation, 
as is the strand-based relation to be given presently. For this reason, and to be 
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consistent with earlier literature such as [FHMV95], we refer to the associated 
modality as knowledge rather than belief, but no great significance should be 
attached to this choice, as we saw in Section 3.3. We now turn specifically to 
strand spaces as a basis for knowledge semantics. 



Strand Semantics for Knowledge 

In the conclusion of [THG97] it was suggested that, 

“[what] a protocol participant knows, in virtue of his experience in ex- 
ecuting a protocol, is that he has performed the actions lying on some 
strand s. Thus, the real world must include some bundle C such that s 
is contained in C. The beliefs that the participant may justifiably hold 
are those that are true in every bundle C containing s.” [THG97] 

Thus, a possible world on this approach is simply a bundle. This is a reason- 
able approach for reasoning about some protocol features. However, we found it 
also worthwhile to include in the definition of possible worlds the nodes within 
bundles. We did this in order to capture temporal aspects of the above authenti- 
cation logics, specifically freshness. This will also facilitate the addition of richer 
temporal formulae to the logic, as in [Syv93a]. 

Neither strand spaces nor bundles have a notion of global time. Thus we 
cannot have an indistinguishability relation that corresponds directly to the 
above. However, (C,s,i) picks a unique point (s,f) in bundle C and partitions 
Nc into : (t,j) {s,i)} and {{t,j) : {t,j) -^c (s,*)}. This partition allows 

us to define an accessibility relation on nodes in bundles based on local time. 

1. Given a strand s, let princ(s) refer to the principal whose strand s is. 

2. Given a node (s,f) and a strand t in a bundle C, let the restriction oft to 
{s,i) in C be tr(t) \ {s,i) = (tr(t)i, . . . ,tr(t)j), where {t,j) is the greatest 
node on t s.t. {t,j) :<c (s,i). 

With this notation in place we can now define an indistinguishability relation. 
Assume bundles C, C , and strands s, s', and indices i, i' such that (s, i) €Afc and, 
(s',i') S A/"c'- A natural definition, analogous to the runs-and-times definition 
of the traditional literature would be to have (C,s,f) ~p (C',s',f') (i.e., (C,s,i) 
is P -indistinguishable from {C',s',i')) just in case P’s history in C up to (s,i) 
matches P’s history in C' up to (s',i'). This is exactly right. However, just as 
there is no global time in a bundle, there may also be multiple strands associated 
with one principal. The resulting definition is thus: 

(C, s, i) is P -indistinguishable from {O', s', i') (written as {C,sf) ~p (C', s', i')) 
iff 



1. for any t in C s.t. princ(t) = P there exists t' in C s.t. tr(t) [ (s,f) = tr(t') [ 
(s',i') and princ(t') = P, and 

2. the number of strands satisfying clause 1 is the same in C and C . 
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Truth Conditions for BAN-Style Formulae 

The purpose of this section, is to present truth conditions for basic formulae 
of a BAN-style language. The basic notions we cover are freshness, key goodness, 
said and received (got) messages, and jurisdiction. 

Given our definition of above we can now present truth conditions for 
knowledge in this semantics. Let ip be some formula in our language. We will 
define ^ inductively; however the presentation is organized pedagogically rather 
than to respect the inductive construction. We assume the usual truth conditions 
for logical connectives; although we will not discuss compound formulae here. 

(C, s, f) \= P knows if 

iff (C', s', i') \= if ‘At all (C', s', i') s.t. (C, s, i) ~p (C', s', i') 

This definition gives a strand semantics for knowledge in a distributed en- 
vironment. However, we have not yet described what specific types of things 
if might express. Giving truth conditions for the various possibilities is the focus 
of the remainder of this section. 

We can give semantics for formulae expressing the sending and receiving 
of messages without giving any more details about the model. Let M be an 
arbitrary message from our term algebra A. Then, 

(C, s,i) \= P sent M 

iff there is a node {t,j) in C s.t. (i) princ(t) = P, (ii) (t,j) ^ and (iii) 

term((t,j)) = +M. Moreover, 

(C, s,i) \= P received M 

iff there is a node (t,j) in C s.t. (i) princ(t) = P, (ii) (t,j) ^ (s,*), and (iii) 
term((t,J}) = —M. 

To give the truth conditions for other formulae, we must first spell out some 
of the structure of the term algebra and define a notion of submessage. The 
following definitions are taken from [THG99b] and can also be found in the 
preceding strand space papers. 

Assume the following: 

— A set T C A of texts (representing the atomic messages). 

— A set K C A of cryptographic keys disjoint from T, equipped with a unary 
operator inv : K ^ K. 

inv is injective; i.e., that it maps each member of a key pair for an asymmetric 
cryptosystem to the other; and that it maps a symmetric key to itself. 

— Two binary operators 



encr : K x A ^ A 
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We will follow notational conventions, some of which have already been men- 
tioned, and write inv(fc) as encr(fc,M) as {M}fe, and join(a, 6) as (ab). If 
if is a set of keys, K~^ denotes the set of inverses of elements of K. 

The next assumption we make is that A is the algebra freely generated from 
T and K by the two operators encr and join. As noted in [THG99b], this assump- 
tion has been commonly made in this area of research going back to [DY83]. As 
in [THG99b] it is probably stronger than what we ultimately need but is peda- 
gogically convenient. Amongst other things, it implies that encryptions and con- 
catenations are unique and always distinct from each other and from T and K. 

Gentral to the semantics of said formulae is the concept of an ideal. In- 
terestingly, in the strand space papers, it was introduced to formulate general 
facts about the penetrator’s capabilities; while, for this discussion, we will say 
virtually nothing about the nature of the penetrator. 

If AT C K, a AT-ideal of A is a subset / of A such that for all h G I, g G A 
and k G K 

1. hq,qh G I. 

2. {h}k G I. 

The smallest AT-ideal containing h is denoted 

The notion of ideal can be used to define a subterm relation IZ as fol- 
lows [THG98a]. 

Let AT C K. s G A is a K -subterm of t G A, (s \Zk t) iff t G Ik[s]- 

If A' = K in this definition, then we say simply that s is a subterm of t, and 
write s Z t. 

We now give truth conditions for said formulae 

(C, s,i) \= P said M 

iff there is a message M' s.t. (C, s, i) \= P sent M' and M \Zk M' where AT is 
the set of keys possessed by P at {s,i). 

Notice that P is held accountable, e.g., for saying M at n, if he sends {M}k 
at n' < n and he has k at n, even if k was not in his key set until some n" 
s.t. n' A n" < n. 

A definition that does not occur in any of the strand space papers is that of 
a filter. In many contexts, filters are the duals of ideals. In our case, they are 
useful for giving semantics to got formulae, those that express the understood 
messages contained in received messages. (Millen and RueB introduce the same 
idea in [MROO] to reason about secrecy invariants. They call it a “coideal”.) 

If AT C K, a AT-filter of A is a subset A of A such that for all h,g G A and 
k G K 

1 . hg G F implies h G F and g G F 

2. {h}fc G F implies h G F for k~^ G K 

The smallest AT-filter containing h is denoted Aft-jh]. 

In general, the relation between filters and ideals is not so simple because, 
in public-key cryptography, one may have k and not have k~^, or vice versa. 
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However, in this section we are limiting discussion to the symmetric key case, 
k = k ~^ — for which there is a simple relation. (This relation also holds when 
both cognates of a public/private key pair are known.) It is easy to show that 

Claim 4 For all sets of keys K' of the form K U 

g e FK>[h] iff he lK>[g]- 

Thus, for key sets /C of this form, by definition 6.2, s CZk' t iff s G FK'[i\. 
We can now give the truth conditions for got formulae. (We present them for 
the general case.) 



(C, s,i) \= P got M 

iff there is a message M' s.t. (C, s, i) \= P received M' and M G Fk[M'] where 
K is the set of keys possessed by P at (s, i). 

We can use the truth conditions for said and got formulae to further give the 
truth conditions for key goodness. 

{C,s,i)^pJ^Q 

iff, for all (s', i') G Afc, (C, s', i') \= R said {M from Q}k implies either 
(C, s', i') 1= R received {M from Q}k, or R = Q and (C, s', i') \= R said M. 
Moreover, if (C, s', i') |= R said {M}k 

(instead of the stronger (C, s', i’) \= R said {M from Q}k), then R G {P, Q} 
(instead of the stronger R = P). 

Note that these are the truth conditions from [Sv096] with (C, s, i) replacing 
(r, t) and (C, s', i') replacing (r, t') throughout. This was itself based on the truth 
conditions for goodness given in [AT91]. 

Once we have a mechanism to express the beginning of the current epoch, 
we will be able to similarly dispatch the freshness and jurisdiction formulae. In 
order to do that, we must again confront the absence of a global concept of 
time. In the system models for possible world semantics of BAN-like logics, it 
was trivial to stipulate a global time to and then define something as fresh if it 
was not said (by anyone) prior to to- We instead define a concept now as follows. 

For any bundle C, now^ C A/”c, is a nonempty set of incomparable nodes 
(i.e., a nonempty set of nodes s.t. n, n' G nowc implies n n' and n' -f, n). For 
n G Me, we may write ‘nowc < n’ just in case there exists n' G nowc s.t. n' ^ n. 
When it is clear from context which bundle is relevant, we will write simply 
‘now’. 

Thus, 

(C,s,f) \= fresh{M) 

iff for all principals P, (C, s', i') |= P said M implies now ^ (s', i'). 

The truth conditions for jurisdiction assume truth conditions for says formu- 
lae, which the definition of nowc allows us to formulate. 



(C, s,i) \= P says M 
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iff there is a message M' and a node {t,j) in C s.t. (i) princ(t) = P, (ii) 
now A (t,j) A (s,i), (iii) term((t,j)) = +M', and (iv) M M' where K is 
the key set possessed by P at {s,i). 

If is a formula. 

(C,s,i) \= P controls ip 

iff {C,s,i) \= P says p implies {C,s\i') |= p for any s.t. now A (s',T). 

These conditions are similar to those in [AT91] and [Sv094, Sv096], mutatis 
mutandis. Notice that goodness is a condition that is constant across all points 
in the same bundle. And, jurisdiction and freshness are constant across all points 
in the present epoch. Notice also that jurisdiction is restricted to those messages 
that are formulae, rather than messages in general. 

This completes our presentation of truth conditions. Strand based truth con- 
ditions for public keys, Diffie-Hellman, and other aspects of SVO have yet to 
be developed. What we have done is to provide a means by which BAN-style 
requirements can be mapped to strand-style protocol specifications. Something 
like this is necessary for the protocol analysis approach characterized by the di- 
agram at the beginning of this section. For the “strand machine” to process its 
inputs there must be some means for it to combine them. The mapping provides 
such a means. To completely develop the semantic approach using BAN-style 
requirements for a strand-style model, the strand machine itself must be built. 
We conclude with a description of some of other areas where there is still much 
work to be done. 

7 The Future 

In [MeaOOb], Meadows sets out a number of open areas in the application of 
formal methods to cryptographic protocols. The primary focus is beyond simple 
two-party authentication protocols, and that paper is a good place to get an 
idea of where much of the cutting edge research is or soon will be. We finish 
up with a discussion of these open areas, but with a slant towards the kinds of 
formalisms and ideas that have been discussed above. We also try to mention 
some of the recent work which has not been alluded to elsewhere above. Indeed, 
such a large amount of work has been done in formal analysis of authentication 
and other security protocols that, despite the number of references cited herein, 
far more work has gone unmentioned, much of it quite good. 

Appropriately, one of the open areas is in open-ended protocols. The two 
major ways in which a protocol can be open-ended is in what data is sent and 
in who is sending or receiving. We address these in order. 

A protocol may be open-ended in virtue of the data sent. For example, the 
Internet Key Exchange Protocol (IKE) that is part of IPSEC [DH99], includes 
an agreement on a Security Association (SA). The SA includes such things as 
a choice of algorithms and other parameters. But, there is no defined (upper) 
limit on what can be included in an SA. This sort of open-endedness has not been 
formally analyzed as far as we know. Another aspect of IKE is that the SA has 
a more elaborate, indeed open-ended, data structure than a simple cryptographic 
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key. In classic authentication protocols, the data about which we prove authenti- 
cation and secrecy properties is simply a key. In Diffie-Hellman exchange, there 
may be parts contributed by the principals that make up the key, but Diffie- 
Hellman based protocols have been analyzed using VO and SVO [v093, Sv096]. 

Protocols can also be open-ended in the participants involved. An obvious 
example is in various kinds of group protocols. These can be for both group au- 
thentication and group confidentiality properties. One example of such a group 
protocol is a group signature protocol, in which a signature can identify only 
that the signer was from a group unless an additional protocol is run (typically 
with a trusted authority) to reveal the individual responsible for the given signa- 
ture. As introduced in [CvH91], these were perhaps only open-ended in principle 
since there was no efficient means to add members to an existing group. The 
first significant advance on that problem was made in [CS97], and others have 
since followed. There has not been any formal methods work that we know of 
directly on this area. More positive results have been seen in the area of group 
Diffie-Hellman [AST98] . These are essentially Diffie-Hellman type establishments 
for open-ended groups. Meadows was able to analyze these protocols after ex- 
panding NPA [MeaOOa]. More recently. Meadows has presented evaluations of 
secure multicast to the IETF and the IRTF Secure Multicast Group. We have 
begun specification and examination of secure multicast protocols using NPA- 
TRL. Other formal methods work involving groups of arbitrary size can be found 
in [Pau97, BS97]. Both of these papers make use of theorem proving, Isabelle 
and PVS respectively to examine the same protocol. 

Another important open are is denial of service. Meadows has devised 
a framework [MeaOl] for reasoning about denial of service in cryptographic pro- 
tocols, although not a formal method per se. The problem with authentication 
is that it is not only a protection against but a great source of denial-of-service 
attacks. If only authenticated principals are allowed to perform any actions, 
then unauthenticated principals cannot deny service. But, verifying authentica- 
tion typically involves computationally intensive cryptographic operations. Thus, 
initiating many authentic connections can be an even more effective denial-of- 
service attack than simply initiating many connections. Meadows builds on the 
fail-stop concept set out in Section 5.3. The idea is to have the amount of work 
expended to defend a protocol against denial of service increase as the protocol 
progresses. The protocol is analyzed to show that it is fail-stop against an at- 
tacker whose capabilities are within a specified constraint. Note that this is a 
diversion from the Dolev-Yao intruder model that we have assumed throughout, 
up to this point. Obviously a Dolev-Yao intruder can arbitrarily deny service. 
Much of the open work involves backing off from such an unrealistically strong 
attacker to consider properties that can be established in the face of a different 
attacker. 

Electronic commerce, in particular non-repudiation and fair exchange, is an 
area that has seen an explosion of protocols and also some formal work in the 
last several years. In fair exchange, there is no adversary per se. Rather, the 
idea is to make sure that each party gets his goods, signed contract, etc. just in 
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case the other does as well. In non-repudiation, the goal is to have evidence that 
a principal cannot repudiate. This can be evidence of messages sent (evidence of 
origin) or messages received (evidence of receipt). Obviously fair exchange and 
non-repudiation are closely related. The first attempt to reason about this area 
formally was by Kailar using a BAN-like logic [Kai95, Kai96] . The central logical 
construct is Can Prove as in “A Can Prove iJsaysX”. Zhou and Gollman also 
used SVO to reason about non-repudiation properties [ZG98]. We have already 
mentioned Brackin’s verification of the Gybercash main sequence protocol using 
BGNY [Bra97]. A more recent approach to non-repudiation, using temporal logic 
with a game semantics can be found in [KROO] . 

The SET protocol is a good illustrator of several of the complexities we have 
introduced in this section. Like IKE, it is not a single protocol but a collection of 
subprotocols. As mentioned in Section 6.1, the protocol is very large and com- 
plex with many options, yet its specification lacks even an informal statement 
of requirements. It has a more elaborate structure than just a key on which 
principals must agree: there is a transaction on which the customer, merchant, 
and bank must agree, but parts of the transaction are hidden from some of the 
principals and parts are added to it as the protocol progresses. And, the reason 
that parts of the transaction are hidden is because the principals are mutually 
mistrusting and attempting some sort of non-repudiable fair exchange. Nonethe- 
less, NPATRL was adapted to express requirements for payments in SET and 
related protocols by adding abstract structures for which some of the compo- 
nents are not revealed [MS98]. Also, the cardholder registration subprotocol has 
been verified using Isabelle and HOL [BMPTOO]. Recall that in SVO and the 
AUTLOG based logic of [WK96] one can reason about principals’ beliefs con- 
cerning messages in which not all the parts are recognizable. This would seem 
naturally generalizable to SET. In [KN98], Kessler and Neuman devised a logic 
for reasoning about payment in SET that combine elements from these logics, 
from Kailar’s logic of accountability, and from the Stubblebine- Wright logic of 
recent security [SW96]. 

These large protocol suites raise still another open issue: protocol compos- 
ability. The fail-stop protocols of Section 5.3 constitute one answer to this prob- 
lem. But are there less onerous design restrictions that can be imposed (similar 
constraints on composition are given in [HT96])? It might seem that protocol 
composability is completely guaranteed by having only EES protocols. However, 
even when the protocols are all EES, the application environment generally will 
not be. Thus, there are still oracles available for active attacks. 

Suppose that principals are willing to use keys obtained through a key- 
distribution protocol before the protocol completes. This is sometimes called 
“eager” use of keys in the literature. Only if the authentication protocol does 
not complete within some reasonable timeout is there an alarm or noting of 
anomaly in the logs. This eagerness might be all the more reasonable if the 
protocol distributing the keys is EES. In this case, there would seem to be no 
possibility of mistake about who the session key is for, who the relevant princi- 
pals are, or the roles they each play (i.e., initiator or responder). But, allowing 
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eager use of keys in an application that authenticates a random challenge by en- 
cryption using the session key could be used to attack the protocol. (This could 
be a variant of the sensor example of Protocol 6.) 

Specifically, suppose Alice begins NSSK (Protocol 1) for a session with Bob, 
the attacker prevents the third message from arriving. Then, for the application 
challenge-response he produces: 

Application Message 1 As — > A : ns 

Application Message 2 Eb ■ {nB}Kab 

The attacker uses the response from Alice for the fourth message in NSSK, and 
intercepts the final message from Alice to Bob. Alice will now be spoofed into 
thinking she has completed a handshake with Bob when Bob was never present. 

This attack is even possible if NSSK is strengthened to be made EPS. The 
point is to show that the applications that use keys established in an authenti- 
cation protocol must also be considered. This aspect of protocol composability 
has received only a little attention. A version of this attack and related issues 
are discussed in [CMSOl]. Besides general composable protocol design, there has 
also been a little work done into showing that particular protocols are compos- 
able [Mea99a, THG99a]. 

Another type of composability is between protocols and the cryptographic 
algorithms they employ. Protocol analysis as we have described it herein has 
treated cryptography as a black box, but some protocols and algorithms are 
secure if used in one combination while they are insecure in different combi- 
nations. Formal work going beyond black box treatments of cryptography in 
protocol analysis is just beginning [AROO, CanOO, .JiirOO]. 

We mentioned the inappropriateness of Dolev-Yao adversaries for modeling 
denial-of-service attacks. They are also clearly inadequate for exchange protocols 
involving mutually mistrusting parties. Another area in which a Dolev-Yao ad- 
versary is simply too strong is anonymity. Anonymity services that have either 
been designed to be practical for most applications or that have actually been 
fielded are simply broken against a Dolev-Yao adversary [Oni, Ano, Cro, Frc]. 
One reason is that anonymity for all of these involves passing messages through 
an intermediate point so as to obscure identity of an originator from anyone ob- 
serving a transmission. Some involve hopping through several points and some 
change the appearance of messages at each point so that parts of the transmis- 
sion cannot be compared and seen to he parts of the same transmission. No 
matter how many of these precautions are taken, in a system where all messages 
pass through the intruder, the intruder will know exactly who is talking to whom 
(and possibly what is being said unless confidentiality is also protected). There 
are communication mechanisms that are secure against a Dolev-Yao intruder, 
e.g., dining cryptographer (DC) nets [Cha88]. However, nothing that is prac- 
tical for widely used email, Web browsing, remote login, etc. is secure against 
a Dolev-Yao intruder. In [SS99], an epistemic model and logic was introduced 
for reasoning about group principals. This built on ideas in [FHMV95]. Recall 
from Section 6.2 that the usual model of computation associated with these log- 
ics has a single principal to represent the environment/penetrator. This is in 
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perfect keeping with the Dolev-Yao model. However, in [SS99], all communica- 
tion principals, including the environment must be specified. And, there is in 
fact no single environment. Rather, there are many environment principals that 
have various capabilities and properties and that can be assembled in a variety 
of ways, i.e., into various sorts of group principals. One can then reason about 
various properties associated with a group of principals (the ‘good guys’) that 
another group of principals (the intruder) can actively or passively determine. 
For example, a particular distributed intruder may be able to determine that 
some (atomic) subprincipal of a group principal of cardinality n was the source 
of a message, but cannot narrow the cardinality lower than n. Work is under- 
way to combine this approach, which has an intuitive yet formal expressiveness, 
with a CSP based approach [SS96]. The intent is to use the CSP as a semantics, 
much as the strand semantics for BAN described in Section 6.2. The language 
in [SS99] includes threshold-group principals and other primitives that should 
make it applicable to other areas besides anonymity. 

Childhood’s End 

Specification and analysis of basic authentication protocols has been the focus 
of much of the above discussion — and much of the work in the last dozen years 
of formal methods in application to cryptographic protocols. The main concepts 
have been extensively explored and both intuitive and fully automated tech- 
niques have been developed, techniques that now do a thorough job and require 
no great sophistication. It has been several years since merely documenting a new 
attack on such protocols or devising a new formal method for reasoning about 
them was sufficient for publication in even small workshops. This is a positive 
sign. More complex protocols and protocols to accomplish more ambitious and 
subtle goals continue to come along. Formal methods are increasingly employed 
in the specification and analysis of protocols that are more than academic ex- 
ercises: commercial products, complex protocol suites, international standards, 
etc. And, they have begun to have an impact in the real-world protocols that 
are being deployed. At the same time there has been a resurgence in theoretical 
models of both the new and the classic concepts, and these have in turn influ- 
enced the development and refinement of formal methods for protocol analysis 
and even design. It’s an exciting time to be in the field. 
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Abstract. Access control is the process of mediating every request to 
resources and data maintained by a system and determining whether 
the request should be granted or denied. The access control decision is 
enforced by a mechanism implementing regulations established by a secu- 
rity policy. Different access control policies can be applied, corresponding 
to different criteria for defining what should, and what should not, be 
allowed, and, in some sense, to different definitions of what ensuring se- 
curity means. In this chapter we investigate the basic concepts behind 
access control design and enforcement, and point out different security 
requirements that may need to be taken into consideration. We discuss 
several access control policies, and models formalizing them, that have 
been proposed in the literature or that are currently under investigation. 



1 Introduction 

An important requirement of any information management system is to protect 
data and resources against unauthorized disclosure {secrecy) and unauthorized 
or improper modifications {integrity), while at the same time ensuring their avail- 
ability to legitimate users {no denials-of-service) . Enforcing protection therefore 
requires that every access to a system and its resources be controlled and that 
all and only authorized accesses can take place. This process goes under the 
name of access control. The development of an access control system requires 
the definition of the regulations according to which access is to be controlled 
and their implementation as functions executable by a computer system. The 
development process is usually carried out with a multi-phase approach based 
on the following concepts: 

Security policy: it defines the (high-level) rules according to which access con- 
trol must be regulated.^ 

^ Often, the term policy is also used to refer to particular instances of a policy, that 
is, actual authorizations and access restrictions to be enforced (e.g.. Employees can 
read bulletin-board). 
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Security model: it provides a formal representation of the access control secu- 
rity policy and its working. The formalization allows the proof of properties 
on the security provided by the access control system being designed. 
Security mechanism: it defines the low level (software and hardware) func- 
tions that implement the controls imposed by the policy and formally stated 
in the model. 

The three concepts above correspond to a conceptual separation between 
different levels of abstraction of the design, and provides the traditional advan- 
tages of multi-phase software development. In particular, the separation between 
policies and mechanisms introduces an independence between protection require- 
ments to be enforced on the one side, and mechanisms enforcing them on the 
other. It is then possible to: i) discuss protection requirements independently 
of their implementation, ii) compare different access control policies as well as 
different mechanisms that enforce the same policy, and Hi) design mechanisms 
able to enforce multiple policies. This latter aspect is particularly important: if 
a mechanism is tied to a specific policy, a change in the policy would require 
changing the whole access control system; mechanisms able to enforce multiple 
policies avoid this drawback. The formalization phase between the policy defi- 
nition and its implementation as a mechanism allows the definition of a formal 
model representing the policy and its working, making it possible to define and 
prove security properties that systems enforcing the model will enjoy [54]. There- 
fore, by proving that the model is “secure” and that the mechanism correctly 
implements the model, we can argue that the system is “secure” (w.r.t. the defi- 
nition of security considered) . The implementation of a correct mechanism is far 
from being trivial and is complicated by the need to cope with possible security 
weaknesses due to the implementation itself and by the difficulty of mapping the 
access control primitives to a computer system. The access control mechanism 
must work as a reference monitor, that is, a trusted component intercepting each 
and every request to the system [5]. It must also enjoy the following properties: 

— tamper-proof : it should not be possible to alter it (or at least it should not 
be possible for alterations to go undetected); 

— non-bypassable\ it must mediate all accesses to the system and its resources; 

— security kernel', it must be confined in a limited part of the system (scattering 
security functions all over the system implies that all the code must be 
verified); 

— small: it must be of limited size to be susceptible of rigorous verification 
methods. 

Even the definition of access control policies (and their corresponding mod- 
els) is far from being a trivial process. One of the major difficulty lies in the 
interpretation of, often complex and sometimes ambiguous, real world security 
policies and in their translation in well defined and unambiguous rules enforce- 
able by a computer system. Many real world situations have complex policies, 
where access decisions depend on the application of different rules coming, for 
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example, from laws, practices, and organizational regulations. A security policy 
must capture all the different regulations to be enforced and, in addition, must 
also consider possible additional threats due to the use of a computer system. 
Access control policies can be grouped into three main classes: 

Discretionary (DAC) (authorization-based) policies control access based on 
the identity of the requestor and on access rules stating what requestors are 
(or are not) allowed to do. 

Mandatory (MAC) policies control access based on mandated regulations de- 
termined by a central authority. 

Role- based (RBAC) policies control access depending on the roles that users 
have within the system and on rules stating what accesses are allowed to 
users in given roles. 

Discretionary and role-based policies are usually coupled with (or include) an 
administrative policy that defines who can specify authorizations/rules governing 
access control. 

In this chapter we illustrate different access control policies and models that 
have been proposed in the literature, also investigating their low level imple- 
mentation in terms of security mechanisms. In illustrating the literature and the 
current status of access control systems, of course, the chapter does not pretend 
to be exhaustive. However, by discussing different approaches with their advan- 
tages and limitations, this chapter hopes to give an idea of the different issues to 
be tackled in the development of an access control system, and of good security 
principles that should be taken into account in the design. 

The chapter is structured as follows. Section 2 introduces the basic concepts 
of discretionary policies and authorization-based models. Section 3 shows the 
limitation of authorization-based controls to introduce the basis for the need of 
mandatory policies, which are then discussed in Section 4. Section 5 illustrates 
approaches combining mandatory and discretionary principles to the goal of 
achieving mandatory information flow protection without loosing the flexibility 
of discretionary authorizations. Section 6 illustrates several discretionary poli- 
cies and models that have been proposed. Section 7 illustrates role-based access 
control policies. Finally, Section 8 discusses advanced approaches and directions 
in the specification and enforcement of access control regulations. 

2 Basic Concepts of Discretionary Policies 

Discretionary policies enforce access control on the basis of the identity of the 
requestors and explicit access rules that establish who can, or cannot, execute 
which actions on which resources. They are called discretionary as users can be 
given the ability of passing on their privileges to other users, where granting 
and revocation of privileges is regulated by an administrative policy. Different 
discretionary access control policies and models have been proposed in the liter- 
ature. We start in this section with the early discretionary models, to convey the 
basic ideas of authorization specifications and their enforcement. We will come 
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back to discretionary policies after having dealt with mandatory controls. We 
base the discussion of the “primitive” discretionary policies on the access matrix 
model. 

2.1 The Access Matrix Model 

The access matrix model provides a framework for describing discretionary access 
control. First proposed by Lampson [-53] for the protection of resources within 
the context of operating systems, and later refined by Graham and Denning [41], 
the model was subsequently formalized by Harrison, Ruzzo, and Ullmann (HRU 
model) [44], who developed the access control model proposed by Lampson to 
the goal of analyzing the complexity of determining an access control policy. The 
original model is called access matrix since the authorization state, meaning the 
authorizations holding at a given time in the system, is represented as a matrix. 
The matrix therefore gives an abstract representation of protection systems. 
Although the model may seem primitive, as richer policies and languages have 
been investigated subsequently (see Section 6) , its treatment is useful to illustrate 
some aspects to be taken into account in the formalization of an access control 
system. 

A first step in the development of an access control system is the identification 
of the objects to be protected, the subjects that execute activities and request 
access to objects, and the actions that can be executed on the objects, and that 
must be controlled. Subjects, objects, and actions may be different in different 
systems or application contexts. For instance, in the protection of operating 
systems, objects are typically files, directories, or programs; in database systems, 
objects can be relations, views, stored procedures, and so on. It is interesting to 
note that subjects can be themselves objects (this is the case, for example, of 
executable code and stored procedures). A subject can create additional subjects 
(e.g., children processes) in order to accomplish its task. The creator subject 
acquires control privileges on the created processes (e.g., to be able to suspend 
or terminate its children). 

In the access matrix model, the state of the system is defined by a triple 
(S', 0,A), where S is the set of subjects, who can exercise privileges; O is the 
set of objects, on which privileges can be exercised (subjects may be considered 
as objects, in which case SCO); and A is the access matrix, where rows corre- 
spond to subjects, columns correspond to objects, and entry A[s,o] reports the 
privileges of s on o. The type of the objects and the actions executable on them 
depend on the system. By simply providing a framework where authorizations 
can be specified, the model can accommodate different privileges. For instance, 
in addition to the traditional read, write, and execute actions, ownership (i.e., 
property of objects by subjects), and control (to model father-children relation- 
ships between processes) can be considered. Figure 1 illustrates an example of 
access matrix. 

Changes to the state of a system is carried out through commands that can 
execute primitive operations on the authorization state, possibly depending on 
some conditions. The HRU formalization identified six primitive operations that 
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Fig. 1. An example of access matrix 



describe changes to the state of a system. These operations, whose effect on the 
authorization state is illustrated in Figure 2, correspond to adding and removing 
a subject, adding and removing an object, and adding and removing a privilege. 
Each command has a conditional part and a body and has the form 



command c(a;i, . . . , Xk) 

if ri in A[xsi-iXo^] and 
T 2 in A[xs 2 ,Xo 2 ] and 



r™ in A[xs„,XoJ\ 

then opi 
OP2 



OPn 

end. 

with n > 0,TO > 0. Here ri,...,rm are actions, opi,...,op„ are primitive 
operations, while Si, ..., Sm and oi, ..., Om are integers between 1 and k. If m=0, 
the command has no conditional part. 

For example, the following command creates a file and gives the creating 
subject ownership privilege on it. 

command CREATE (creator, file) 
create object file 

enter Own into A [creator, file] end. 

The following commands allow an owner to grant to others, and revoke ^from 
others, a privilege to execute an action on her files. 

command CONFER^ (owner, friend, file) 
if Own in A [owner, file] 

then enter a into A[friend,file] end. 
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OPERATION (op) 


CONDITIONS 


NEW STATE (Q hop Q') 


enter r into A[s,o] 


SG S 
o e o 


S' = S 
O' = o 

A'[s, o] = A[s, o] U {r} 

A'[si, Oj] = A[si, Oj] V(si, Oj) A (s, o) 


delete r from A[s, o] 


s € 5 
0 e o 


S' = s 
O' = o 

A'[s,o\ = A[s,o] \ {r} 

A'[si, Oj] = A[si, Oj] y{si, Oj) A (s> o) 


create subject s' 


s' 


S' = S'Uis'} 
o' = Ou{s'} 

A'[s, o] = A[s, o] ys G S,o G O 
A'[s',o]=0 VoeO' 
A'[s,s']=0 ysGS' 


create object o' 


o' 


S' = s 

O' = OU{o'} 

A'[s, o] = A[s, o] Ws G S,o G O 
A'[s,o']=0 VseS" 


destroy subject s' 


s' G S 


S' = S\{s'} 

O' = 0\ {s'} 

A'[s, o] = A[s, o] Vs G S' ,0 G O' 


destroy object o' 


o' GO 
o' 


Ql — Q 

O' = 0\ {o'} 

A'[s, o] = A[s, o] Vs G S' ,0 G O' 



Fig. 2. Primitive operations of the HRU model 



command REVOKEo(owner, ex-friend, file) 
if Own in A [owner, file] 

then delete a from ^[ex-friend, file] end. 

Note that here a is not a parameter, but an abbreviation for defining many 
similar commands, one for each value that a can take (e.g., CONFERj-gg^^^, 
REVOKE^j.j^g). Since commands are not parametric w.r.t. actions, a different 
command needs to be specified for each action that can be granted/revoked. 

Let Q \~op Q' denote the execution of operation op on state Q, resulting 
in state Q' . The execution of command c(ai,...,afe) on a system state Q = 
(S', O, A) causes the transition from state Q to state Q' such that 3 Qi, . . . , Qn 
for which Q hop* Qi hop^ hop. = Q', where op* . . . op^ are the primitive 
operations opi . . . op„ in the body (operational part) of command c, in which 
actual parameters Oi are substituted for each formal parameters Xi, i := 1, . . . , fc. 
If the conditional part of the command is not verified, then the command has 
no effect and Q = Q' . 

Although the HRU model does not include any buil-in administrative poli- 
cies, the possibility of defining commands allows their formulation. Adminis- 
trative authorizations can be specified by attaching flags to access privileges. 
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For instance, a copy flag, denoted *, attached to a privilege may indicate that 
the privilege can be transferred to others. Granting of authorizations can then 
be accomplished by the execution of commands like the one below (again here 
TRANSFERa is an abbreviation for as many commands as there are actions). 

command TRANSFERa(subj, friend, file) 
if a* in A[subj,file] 

then enter a into A [friend, file] end. 

The ability of specifying commands of this type clearly provides flexibility as 
different administrative policies can be taken into account by defining appropri- 
ate commands. For instance, an alternative administrative flag (called transfer 
only and denoted -I-) can be supported, which gives the subject the ability of 
passing on the privilege to others but for which, so doing, the subject looses 
the privilege. Such a flexibility introduces an interesting problem referred to as 
safety, and concerned with the propagation of privileges to subjects in the sys- 
tem. Intuitively, given a system with initial configuration Q, the safety problem 
is concerned with determining whether or not a given subject s can ever acquire 
a given access a on an object o, that is, if there exists a sequence of requests 
that executed on Q can produce a state Q' where a appears in a cell A[s, o] 
that did not have it in Q. (Note that, of course, not all leakages of privileges 
are bad and subjects may intentionally transfer their privileges to “trusworthy” 
subjects. Trustworthy subjects are therefore ignored in the analysis.) It turns 
out that the safety problem is undecidable in general (it can be reduced to 
the halting problem of a Turing machine) [4]. It remains instead decidable for 
cases where subjects and objects are finite, and in mono- operational systems, 
that is, systems where the body of commands can have at most one opera- 
tion (while the conditional part can still be arbitrarily complex). However, as 
noted in [81], mono-operational systems have the limitation of making create 
operations pretty useless: a single create command cannot do more than adding 
an empty row/column (it cannot write anything in it). It is therefore not possi- 
ble to support ownership or control relationships between subjects. Progresses in 
safety analysis were made in a later extension of the HRU model by Sandhu [81], 
who proposed the TAM (Typed Access Matrix) model. TAM extends HRU with 
strong typing: each subject and object has a type; the type is associated with the 
subjects/objects when they are created and thereafter does not change. Safety 
results decidable in polynomial time for cases where the system is monotonic 
(privileges cannot be deleted), commands are limited to three parameters, and 
there are no cyclic creates. Safety remains undecidable otherwise. 

2.2 Implementation of the Access Matrix 

Although the matrix represents a good conceptualization of authorizations, it 
is not appropriate for implementation. In a general system, the access matrix 
will be usually enormous in size and sparse (most of its cells are likely to be 
empty). Storing the matrix as a two-dimensional array is therefore a waste of 
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memory space. There are three approaches to implementing the access matrix 
in a practical way: 

Authorization Table Non empty entries of the matrix are reported in a ta- 
ble with three columns, corresponding to subjects, actions, and objects, re- 
spectively. Each tuple in the table corresponds to an authorization. The 
authorization table approach is generally used in DBMS systems, where au- 
thorizations are stored as catalogs (relational tables) of the database. 
Access Control List (ACL) The matrix is stored by column. Each object is 
associated with a list indicating, for each subject, the actions that the subject 
can exercise on the object. 

Capability The matrix is stored by row. Each user has associated a list, called 
capability list, indicating, for each object, the accesses that the user is allowed 
to exercise on the object. 

Figure 3 illustrates the authorization table, ACLs, and capabilities, respec- 
tively, corresponding to the access matrix in Figure 1. 

Capabilities and ACLs present advantages and disadvantages with respect 
to authorization control and management. In particular, with ACLs it is imme- 
diate to check the authorizations holding on an object, while retrieving all the 
authorizations of a subject requires the examination of the ACLs for all the ob- 
jects. Analogously, with capabilities, it is immediate to determine the privileges 
of a subject, while retrieving all the accesses executable on an object requires the 
examination of all the different capabilities. These aspects affect the efficiency 
of authorization revocation upon deletion of either subjects or objects. 

In a system supporting capabilities, it is sufficient for a subject to present 
the appropriate capability to gain access to an object. This represents an advan- 
tage in distributed systems since it permits to avoid repeated authentication of 
a subject: a user can be authenticated at a host, acquire the appropriate capa- 
bilities and present them to obtain accesses at the various servers of the system. 
However, capabilities are vulnerable to forgery (they can be copied and reused 
by an unauthorized third party) . Another problem in the use of capability is the 
enforcement of revocation, meaning invalidation of capabilities that have been 
released. 

A number of capability-based computer systems were developed in the 1970s, 
but did not prove to be commercially successful. Modern operating systems 
typically take the ACL-based approach. Some systems implement an abbreviated 
form of ACL by restricting the assignment of authorizations to a limited number 
(usually one or two) of named groups of users, while individual authorizations are 
not allowed. The advantage of this is that ACLs can be efficiently represented as 
small bit-vectors. For instance, in the popular Unix operating system, each user 
in the system belongs to exactly one group and each file has an owner (generally 
the user who created it), and is associated with a group (usually the group of 
its owner). Authorizations for each file can be specified for the file’s owner, for 
the group to which the file belongs, and for “the rest of the world” (meaning 
all the remaining users). No explicit reference to users or groups is allowed. 
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Fig. 3. Authorization table, ACLs, and capabilities for the matrix in Figure 1 



Authorizations are represented by associating with each object an access control 
list of 9 bits: bits 1 through 3 reflect the privileges of the Ale’s owner, bits 
4 through 6 those of the user group to which the file belongs, and bits 7 through 
9 those of all the other users. The three bits correspond to the read (r), write (w), 
and execute (x) privilege, respectively. For instance, ACL rwxr-x — x associated 
with a file indicates that the file can be read, written, and executed by its owner, 
read and executed by users belonging to the group associated with the file, and 
executed by all the other users. 
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3 Vulnerabilities of the Discretionary Policies 

In defining the basic concepts of discretionary policies, we have referred to ac- 
cess requests on objects submitted by users, which are then checked againsts the 
users’ authorizations. Although it is true that each request is originated because 
of some user’s actions, a more precise examination of the access control problem 
shows the utility of separating users from subjects. Users are passive entities 
for whom authorizations can be specified and who can connect to the system. 
Once connected to the system, users originate processes (subjects) that execute 
on their behalf and, accordingly, submit requests to the system. Discretionary 
policies ignore this distinction and evaluate all requests submitted by a process 
running on behalf of some user against the authorizations of the user. This as- 
pect makes discretionary policies vulnerable from processes executing malicious 
programs exploiting the authorizations of the user on behalf of whom they are 
executing. In particular, the access control system can be bypassed by Trojan 
Horses embedded in programs. A Trojan Horse is a computer program with an 
apparently or actually useful function, which contains additional hidden func- 
tions that surreptitiously exploit the legitimate authorizations of the invoking 
process. (Viruses and logic bombs are usually transmitted as Trojan Horses.) 
A Trojan Horse can improperly use any authorizations of the invoking user, for 
example, it could even delete all files of the user (this destructive behavior is not 
uncommon in the case of viruses). This vulnerability to Trojan Horses, together 
with the fact that discretionary policies do not enforce any control on the flow of 
information once this information is acquired by a process, makes it possible for 
processes to leak information to users not allowed to read it. All this can happen 
without the cognizance of the data administrator/owner, and despite the fact 
that each single access request is controlled against the authorizations. To un- 
derstand how a Trojan Horse can leak information to unauthorized users despite 
the discretionary access control, consider the following example. Assume that 
within an organization, Vicky, a top-level manager, creates a file Market con- 
taining important information about releases of new products. This information 
is very sensitive for the organization and, according to the organization’s policy, 
should not be disclosed to anybody besides Vicky. Consider now John, one of 
Vicky’s subordinates, who wants to acquire this sensitive information to sell it 
to a competitor organization. To achieve this, John creates a file, let’s call it 
Stolen, and gives Vicky the authorization to write the file. Note that Vicky may 
not even know about the existence of Stolen, or about the fact that she has the 
write authorization on it. Moreover, John modifies an application generally used 
by Vicky, to include two hidden operations, a read operation on file Market and 
a write operation on file Stolen (Figure 4(a)). Then, he gives the new applica- 
tion to his manager. Suppose now that Vicky executes the application. Since the 
application executes on behalf of Vicky, every access is checked against Vicky’s 
authorizations, and the read and write operations above are allowed. As a result, 
during execution, sensitive information in Market is transferred to Stolen and 
thus made readable to the dishonest employee John, who can then sell it to the 
competitor (Figure 4(b)). The reader may object that there is little point in 
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Fig. 4. An example of Trojan Horse improperly leaking information 
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defending against Trojan Horses leaking information flow: such an information 
flow could have happened anyway, by having Vicky explicitly tell this informa- 
tion to John, possibly even off-line, without the use of the computer system. 
Here is where the distinction between users and subjects operating on their be- 
half comes in. While users are trusted to obey the access restrictions, subjects 
operating on their behalf are not. With reference to our example, Vicky is trusted 
not to release the sensitive information she knows to John, since, according to 
the authorizations, John cannot read it. However, the processes operating on 
behalf of Vicky cannot be given the same trust. Processes run programs which, 
unless properly certified, cannot be trusted for the operations they execute. For 
this reason, restrictions should be enforced on the operations that processes 
themselves can execute. In particular, protection against Trojan Horses leaking 
information to unauthorized users requires controlling the flows of information 
within processes execution and possibly restricting them. Mandatory policies 
provide a way to enforce information flow control through the use of labels. 



4 Mandatory Policies 

Mandatory security policies enforce access control on the basis of regulations 
mandated by a central authority. The most common form of mandatory policy 
is the multilevel security policy, based on the classifications of subjects and ob- 
jects in the system. Objects are passive entities storing information. Subjects 
are active entities that request access to the objects. Note that there is a dis- 
tinction between subjects of the mandatory policy and the authorization subjects 
considered in the discretionary policies. While authorization subjects typically 
correspond to users (or groups thereof), mandatory policies make a distinction 
between users and subjects. Users are human beings who can access the system, 
while subjects are processes (i.e., programs in execution) operating on behalf of 
users. This distinction allows the policy to control the indirect accesses (leakages 
or modifications) caused by the execution of processes. 

4.1 Security Classifications 

In multilevel mandatory policies, an access class is assigned to each object and 
subject. The access class is one element of a partially ordered set of classes. 
The partial order is defined by a dominance relationship, which we denote with 
>. While in the most general case, the set of access classes can simply be any 
set of labels that together with the dominance relationship defined on them 
form a POSET (partially ordered set), most commonly an access class is defined 
as consisting of two components: a security level and a set of categories. The 
security level is an element of a hierarchically ordered set, such as Top Secret 
(TS), Secret (S), Confidential (C), and Unclassified (U), where TS > S > C > U. 
The set of categories is a subset of an unordered set, whose elements reflect 
functional, or competence, areas (e.g., NATO, Nuclear, and Army, for military 
systems; Financial, Administration, and Research, for commercial systems). The 
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Fig. 5 . An example of security lattice 



dominance relationship > is then defined as follows: an access class Ci dominates 
(>) an access class C2 iff the security level of ci is greater than or equal to that 
of C2 and the categories of ci include those of C2 . Formally, given a totally ordered 
set of security levels C, and a set of categories C, the set of access classes is AC = 
C X p(C)^, and Vci = (Ai, Ci), C2 = (A2> ^2) : ci > C2 L\ > L2 A C\ 3 C^- 

Two classes ci and C2 such that neither ci > C2 nor C2 > ci holds are said to be 

incomparable. 

It is easy to see that the dominance relationship so defined on a set of access 
classes AC satisfies the following properties. 

— Reflexivity: \/x € AC : x > x 

— Transitivity: Vx, y,z € AC '■ x >y,y > z => x > z 

— Antisymmetry: Vx, y S AC '■ x > y,y > x => x = y 

— Existence of a least upper hound: Vx, y G AC : 3 Iz G AC 

• z > X and z > y 

• yt G AC : t > X and t > y t > z. 

— Existence of a greatest lower bound: Vx,y G AC :3\z G AC 

• X > z and y > z 

• yt G AC : X >t and y >t z > t. 

Access classes defined as above together with the dominance relationship 
between them therefore form a lattice [. 31 ]. Figure 5 illustrates the security lattice 
obtained considering security levels TS and S, with TS>S and the set of categories 
{Nuclear, Army}. 

The semantics and use of the classifications assigned to objects and subjects 
within the application of a multilevel mandatory policy is different depending 
on whether the classification is intended for a secrecy or an integrity policy. We 
next examine secrecy-based and integrity-based mandatory policies. 

^ p(C) denotes the powerset of C. 
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4.2 Secrecy-Based Mandatory Policies 

A secrecy mandatory policy controls the direct and indirect flows of informa- 
tion to the purpose of preventing leakages to unauthorized subjects. Here, the 
semantics of the classification is as follows. The security level of the access class 
associated with an object reflects the sensitivity of the information contained 
in the object, that is, the potential damage that could result from the unau- 
thorized disclosure of the information. The security level of the access class 
associated with a user, also called clearance, reflects the user’s trustworthiness 
not to disclose sensitive information to users not cleared to see it. Categories 
define the area of competence of users and data and are used to provide finer 
grained security classiflcations of subjects and objects than classifications pro- 
vided by security levels alone. They are the basis for enforcing need-to-know 
restrictions (i.e., confining subjects to access information they actually need to 
know to perform their job). 

Users can connect to the system at any access class dominated by their clear- 
ance. A user connecting to the system at a given access class originates a subject 
at that access class. For instance, with reference to the lattice in Figure 5, a user 
cleared (TS , {Nuclear}) can connect to the system as a (S, {Nuclear}), (TS,0), 
or (TS,0) subject. Requests by a subject to access an object are controlled with 
respect to the access class of the subject and the object and granted only if 
some relationship, depending on the requested access, is satisfied. In particular, 
two principles, first formulated by Bell and LaPadula [12], must be satisfied to 
protect information confidentiality: 

No-read-up A subject is allowed a read access to an object only if the access 

class of the subject dominates the access class of the object. 
No-write-down A subject is allowed a write access to an object only if the 

access class of the subject is dominated by the access class of the object. 

Satisfaction of these two principles prevents information to flow from high 
level subjects/objects to subjects/objects at lower (or incomparable) levels, 
thereby ensuring the satisfaction of the protection requirements (i.e., no pro- 
cess will be able to make sensitive information available to users not cleared for 
it). This is illustrated in Figure 6, where four accesses classes composed only of 
a security level (TS, S, C, and U) are taken as example. Note the importance of 
controlling both read and write operations, since both can be improperly used 
to leak information. Consider the example on the Trojan Horse illustrated in 
Section 3. Possible classiflcations reflecting the access restrictions to be enforced 
could be: Secret for Vicky and Market, and Unclassified for John and Stolen. In 
the respect of the no-read-up and no-write-down principles, the Trojan Horse 
will never be able to complete successfully. If Vicky connects to the system as 
a Secret (or Confidential) subject, and thus the application runs with a Secret (or 
Confidential) access class, the write operation will be blocked. If Vicky invokes 
the application as an Unclassified subject, the read operation will be blocked 
instead. 
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Given the no- write-down principle, it is clear now why users are allowed 
to connect to the system at different access classes, so that they are able to 
access information at different levels (provided that they are cleared for it) . For 
instance, Vicky has to connect to the system at a level below her clearance if she 
wants to write some Unclassified information, such as working instructions for 
John. Note that a lower class does not mean “less” privileges in absolute terms, 
but only less reading privileges (see Figure 6). 

Although users can connect to the system at any level below their clearance, 
the strict application of the no-read-up and the no-write-down principles may 
result too rigid. Real world situations often require exceptions to the mandatory 
restrictions. For instance, data may need to be downgraded (e.g., data subject 
to embargoes that can be released after some time). Also, information released 
by a process may be less sensitive than the information the process has read. For 
instance, a procedure may access personal information regarding the employees 
of an organization and return the benefits to be granted to each employee. While 
the personal information can be considered Secret, the benefits can be considered 
Confidential. To respond to situations like these, multilevel systems should then 
allow for exceptions, loosening or waiving restrictions, in a controlled way, to 
processes that are trusted and ensure that information is sanitized (meaning the 
sensitivity of the original information is lost) . 

Note also that DAC and MAC policies are not mutually exclusive, but can 
be applied jointly. In this case, an access to be granted needs both i) the ex- 
istence of the necessary authorization for it, and ii) to satisfy the mandatory 
policy. Intuitively, the discretionary policy operates within the boundaries of the 
mandatory policy: it can only restrict the set of accesses that would be allowed 
by MAC alone. 
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4.3 The Bell-LaPadula Model (Some History) 

The secrecy based control principles just illustrated summarize the basic axioms 
of the security model proposed by David Bell and Leonard LaPadula [12]. Here, 
we illustrate some concepts of the model formalization to give an idea of the 
different aspects to be taken into account in the definition of a security model. 
This little bit of history is useful to understand the complications of formalizing 
a policy and making sure that the policy’ axioms actually ensure protection as 
intended. We note first that different versions of the model have been proposed 
(due to the formalization of new properties [10,12,55], or related to specific ap- 
plication environments [11]), however the basic principles remain the same (and 
are those illustrated in the previous section). Also, here we will be looking only 
at the aspects of the formalization needed to illustrate the concepts we want to 
convey: for the sake of simplicity, the formulation of the model is simplified and 
some aspects are omitted. 

In the Bell and LaPadula model a system is composed of a set of subjects S, 
objects O, and actions A, which includes read and write^. The model also 
assumes a lattice L of access classes and a function X : S U O ^ L that, when 
applied to a subject (object, resp.) in a given state, returns the classification of 
the subject (object, resp.) in that state. A state w S P is defined as a triple 
(6,M, A), where b S p{S x O x A) is the set of current accesses (s,o, a), M is 
the access matrix expressing discretionary permissions (as in the HRU model), 
and A is the association of access classes with subjects and objects. A system 
consists of an initial state vg, a set of requests i?, and a state transition function 
T ■. V X R ^ V that transforms a system state into another state resulting from 
the execution of a request. Intuitively, requests capture acquisition and release of 
accesses, granting and revocation of authorizations, as well as changes of levels. 
The model then defines a set of axioms stating properties that the system must 
satisfy and that express the constraints imposed by the mandatory policy. The 
first version of the Bell and LaPadula model stated the following criteria. 

simple property A state v satisfies the simple security property iff for every 

s € S , o € 0\ (s, o, read) e b A(s) > A(o). 

*-property A state v satisfies the *-security property iff for every s £ S , o G O: 

(s, o, write) G b A(o ) > A(s). 

The two axioms above correspond to the no-read-up and no- write-down prin- 
ciples we have illustrated in Section 4.2. A state is then defined to be secure 
if it satisfies both the simple security property and the *-property. A system 
{vg,R, T) is secure if and only if every state reachable from vg by executing one 
or more finite sequences of requests from R is state secure. 

In the first formulation of their model. Bell and LaPadula provide a Basic 
Security Theorem (BST), which states that a system is secure \i i) its initial 

® For uniformity of the discussion, we use the term “write” here to denote the “write- 
only” (or “append”) action. 



Access Control: Policies, Models, and Mechanisms 



153 



state vq is secure, and ii) the state transition T is security preserving, that is, it 
transforms a secure state into another secure state. 

As noticed by McLean in his example called “System Z” [63], the BST the- 
orem does not actually guarantee security. The problem lies in the fact that no 
restriction, but to be preserving of state security, is put on transitions. In his 
System Z example, McLean shows how failing to control transitions can com- 
promise security. Consider a system Z whose initial state is secure and that has 
only one type of transition: when a subject requests any type of access to an 
object o, every subject and object in the system are downgraded to the lowest 
possible access class and the access is granted. System Z satisfies the Bell and 
LaPadula notion of security, but it is obviously not secure in any meaningful 
sense. The problem pointed out by System Z is that transitions need to be con- 
trolled. Accordingly, McLean proposes extending the model with a new function 
C : S' U O — *■ p(S), which returns the set of subjects allowed to change the level 
of its argument. A transition is secure if it allows changes to the level of a sub- 
ject/object X only by subjects in C'(x); intuitively, these are subjects trusted for 
downgrading. A system {vo,R, T) is secure if and only if i) vq is secure, iij every 
state reachable from vg by executing a finite sequence of one or more requests 
from i? is (BLP) secure, and iiij T is transition secure. 

The problem with changing the security level of subjects and objects was 
not captured formally as an axiom or property in the Bell and LaPadula, but as 
an informal design guidance called tranquility principle. The tranquility princi- 
ple states that the classification of active objects should not be changed during 
normal operation [.55]. A subsequent revision of the model [10] introduced a dis- 
tinction between the level assigned to a subject {clearance) and its current level 
(which could be any level dominated by the clearance), which also implied chang- 
ing the formulation of the axioms, introducing more flexibility in the control. 

Another property included in the Bell and LaPadula model is the discre- 
tionary property which constraints the set of current accesses 6 to be a subset of 
the access matrix M. Intuitively, it enforces discretionary controls. 

4.4 Integrity-based Mandatory Policies: The Biba Model 

The mandatory policy that we have discussed above protects only the confiden- 
tiality of the information; no control is enforced on its integrity. Low classified 
subjects could still be able to enforce improper indirect modifications to objects 
they cannot write. With reference to our organization example, for instance, 
integrity could be compromised if the Trojan Horse implanted by John in the 
application would write data in file Market (this operation would not be blocked 
by the secrecy policy). Starting from the principles of the Bell and LaPadula 
model, Biba [16] proposed a dual policy for safeguarding integrity, which con- 
trols the flow of information and prevents subjects to indirectly modify informa- 
tion they cannot write. Like for secrecy, each subject and object in the system 
is assigned an integrity classification. The classifications and the dominance re- 
lationship between them are defined as before. Example of integrity levels can 
be: Crucial (C), Important (l), and Unknown (U). The semantics of integrity 
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classifications is as follows. The integrity level associated with a user reflects 
the user’s trustworthiness for inserting, modifying, or deleting information. The 
integrity level associated with an object reflects both the degree of trust that 
can be placed on the information stored in the object and the potential damage 
that could result from unauthorized modifications of the information. Again, 
categories define the area of competence of users and data. Access control is 
enforced according to the following two principles: 

No-read-down A subject is allowed a read access to an object only if the access 
class of the object dominates the access class of the subject. 

No- write-up A subject is allowed a write access to an object only if the access 
class of the subject is dominated by the access class of the object. 

Satisfaction of these principles safeguard integrity by preventing information 
stored in low objects (and therefore less reliable) to flow to higher, or incom- 
parable, objects. This is illustrated in Figure 7, where classes composed only of 
integrity levels (C,I, and U) are taken as example. 

The two principles above are the dual of the two principles formulated by 
Bell and LaPadula. Elba’s proposal also investigated alternative criteria for safe- 
guarding integrity, allowing for more dynamic controls. These included the fol- 
lowing two policies. 

Low-water mark for subjects It constraints write operations according to 
the no- write-up principle. No restriction is imposed on read operations. 
However, a subject s that reads an object o has its classification down- 
graded to the greatest lower bound of the classification of the two, that is, 
A'(s) = glb(A(s), A(o)). 

Low-water mark for objects It constraints read operations according to the 
no-read-down principle. No restriction is imposed on write operations. How- 
ever, if a subject s writes an object o, the object has its classification down- 



Access Control: Policies, Models, and Mechanisms 



155 



graded to the greatest lower bound of the classification of the two, that is, 
A'(o) = glb(A(s), A(o)). 

Intuitively, the two policies attempt to apply a more dynamic behavior in the 
enforcement of the constraints. The two approaches suffer however of drawbacks. 
In the low-water mark for subjects approach, the ability of a subject to execute 
a procedure may depend on the order with which operations are requested: 
a subject may be denied the execution of a procedure because of read operations 
executed before. The latter policy cannot actually be considered as safeguarding 
integrity: given that subjects are allowed to write above their level, integrity 
compromises can certainly occur; by downgrading the level of the object the 
policy simply signals this fact. 

As it is visible from Figures 6 and 7, secrecy policies allow the flow of informa- 
tion only from lower to higher (secrecy) classes while integrity policies allow the 
flow of information only from higher to lower (integrity) classes. If both secrecy 
and integrity have to be controlled, objects and subjects have to be assigned two 
access classes, one for secrecy control and one for integrity control. 

A major limitation of the policies proposed by Biba is that they only capture 
integrity compromises due to impoproper information flows. However, integrity 
is a much broader concept and additional aspects should be taken into account 
(see Section 6.5). 

4.5 Applying Mandatory Policies to Databases 

The first formulation of the multilevel mandatory policies, and the Bell LaPadula 
model, simply assumed the existence of objects (information container) to which 
a classification is assigned. This assumption works well in the operating system 
context, where objects to be protected are essentially files containing the data. 
Later studies investigated the extension of mandatory policies to database sys- 
tems. While in operating systems access classes are assigned to files, database 
systems can afford a finer-grained classification. Classification can in fact be con- 
sidered at the level of relations (equivalent to file-level classification in OS), at 
the level of columns (different properties can have a different classification), at 
the level of rows (properties referred to a given real world entity or association 
have the same classification), or at the level of single cells (each data element, 
meaning the value assigned to a property for a given entity or association, can 
have a different classification), this latter being the finest possible classification. 
Early efforts to classifying information in database systems, considered classifi- 
cation at the level of each single element [50,61]. Element-level classification is 
clearly appealing since it allows the assignment of a security class to each single 
real world fact that needs to be represented. For instance, an employee’s name 
can be labeled Unclassified, while his salary can be labeled Secret; also the salary 
of different employees can take on different classifications. However, the support 
of fine-grained classifications together with the obvious constraint of maintaining 
secrecy in the system operation introduces complications. The major complica- 
tion is represented by the so called polyinstantiation problem [49,60], which is 
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Fig. 8. An example of multilevel relation (a) and the unclassified view on it (b) 



probably one of the main reasons why multilevel databases did not have much 
success. Generally speaking, polyinstantiation is the presence in the system of 
multiple instances of the same real world fact or entity, where the instances differ 
for the access class associated with them. 

To illustrate the problem, let us start giving the definition of multilevel re- 
lational database. A relational database is composed of a finite set of relations, 
each defined over a set of attributes Ai , . . . , A„ (columns of the relation) . Each 
relation is composed of a set of tuples G , . . . , tfe (rows of the relation) mapping 
attributes to values over their domain. A subset of the attributes, called key 
attributes, are used to uniquely identify each tuple in the relation, and the fol- 
lowing key constraints are imposed: i) no two tuples can have the same values 
for the key attributes, and ii) key attributes cannot be null. In a multilevel 
relational database supporting element-level labeling, an access class A(t[A]) is 
associated with each element t[A\ in a relation. An example of multilevel relation 
is illustrated in Figure 8(a). Note that the classification associated with a value 
does not represent the absolute sensitivity of the value as such, but rather the 
sensitivity of the fact that the attribute takes on that value for a specific entity 
in the real world. For instance, classification Secret associated with value 150K 
of the last tuple is not the classification of value 150K by itself, but of the fact 
that it is the salary of Sam."'’ 

Access control in multilevel DBMSs applies the two basic principles discussed 
in Section 4.2, although the no- write-up restriction is usually reduced to the prin- 
ciple of “write at their own level”. In fact, while write-up operations can make 
sense in operating systems, where a file is seen as an information container and 
subjects may need to append low-level data in a high-level container, element- 
level classification nullifies this reasoning. 

Subjects at different levels have different views on a relation, which is the view 
composed only of elements they are cleared to see (i.e., whose classification they 
dominate). For instance, the view of an Unclassified subject on the multilevel 
relation in Figure 8(a) is the table in Figure 8(b). Note that, in principle, to not 
convey information, the Unclassified subject should see no difference between 
values that are actually null in the database and those that are null since they 

^ Note that this is not meant to say that the classification of an element is independent 
of its value. As a matter of fact it can depend on the value; for instance a classification 
rule may state that all salaries above lOOK must be classified as Secret [30]. 
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Fig. 9. An example of a relation with polyinstantiation (a) and the unclassified 
view on it (b) 



have a higher classification.® To produce a view consistent with the relational 
database constraints the classification needs to satisfy at least the following two 
basic constraints: i) the key attributes must be uniformly classified, and ii) the 
classifications of nonkey attributes must dominate that of key attributes. If it 
were not so, the view at some levels would contain a null value for some or all 
key attributes (and therefore would not satisfy the key constraints). 

To see how polyinstantiation can arise, suppose that an Unclassified subject, 
whose view on the table in Figure 8(a) is as illustrated in Figure 8(b), requests 
insertion of tuple (Ann, Deptl, lOOK). According to the key constraints im- 
posed by the relational model, no two tuples can have the same value for the 
key attributes. Therefore if classifications were not taken into account, the in- 
sertion could have not been accepted. The database could have two alternative 
choices: i) tell the subject that a tuple with the same key already exists, or ii) 
replace the old tuple with the new one. The first solution introduces a covert 
channel^, since by rejecting the request the system would be revealing protected 
information (meaning the existence of a Secret entity named Ann), and clearly 
compromises secrecy. On the other hand, the second solution compromises in- 
tegrity, since high classified data would be lost, being overridden by the newly 
inserted tuple. Both solutions are therefore inapplicable. The only remaining so- 
lution would then be to accept the insertion and manage the presence of both 
tuples (see Figure 9(a)). Two tuples would then exist with the same value, but 
different classification, for their key (polyinstantiated tuples). A similar situation 
happens if the unclassified subject requests to update the salary of Sarni to value 
lOOK. Again, telling the subject that a value already exists would compromise 
secrecy (if the subject is not suppose to distinguish between real nulls and values 
for which it does not have sufficient clearance), while overwriting the existing 
Secret value would compromise integrity (as the Secret salary would be lost). 

® Some proposals do not adopt this assumption. For instance, in LDV [43], a special 
value “restricted” appears in a subject’s view to denote the existence of values not 
visible to the subject. 

® We will talk more about covert channels in Section 4.6. 
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(b) 

Fig. 10. An example of a relation with polyinstantiation (a) and the unclassified 
view on it (b) 
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The only remaining solution would therefore seem to be to accept the insertion 
(Figure 9(a)), implying then the existence of two tuples with the same value and 
classification for their key, but with different value and classification for one of 
their attributes {polyinstantiated elements). Note that, when producing the view 
visible to a subject in the presence of polyinstantiation, the DBMS must com- 
pletely hide those tuples with high polyinstiated values that the subject cannot 
see. For instance, an unclassified subject querying the relation in Figure 9(a) will 
see only one tuple for Ann and Sam (see Figure 9(b)). 

Polyinstantiation can also occur because of requests by high level subjects. 
For instance, consider again the relation in Figure 8(a) and assume a Secret sub- 
ject requests to insert tuple (Bob , Dept2 , 200K) . A tuple with key Bob already 
exists at level Unclassified. If key uniqueness is to be preserved, the system can ei- 
ther i) inform the subject of the conflict and refuse the insertion, or ii) overwrite 
the existing tuple. Again, the solution of refusing insertion is not advisable: al- 
though it would not leak protected information, it introduces denials- of- service, 
since high level subjects would not be allowed to insert data. The second solution 
also is not viable since it would introduce a covert channel due to the effect that 
the overwriting would have on the view of lower level subjects (which would see 
the Unclassified tuple disappear). Again, the only possible solution seems to be 
to accept the insertion and have the two (polyinstantiated) tuples coexist (see 
Figure 10(a)). A similar problem would arise at the attribute level, for update 
operations. For instance, if a secret subject requires updating Jim’s salary to 
150K, polyinstantiated elements would be introduced (see Figure 10(a)). 

Earlier work in multilevel database systems accepted polyinstantiation as 
an inevitable consequence of fine-grained classification and attempted to clarify 
the semantics of the database states in the presence of polyinstantiation [-50,61]. 
For instance, the presence of two tuples with the same value, but different clas- 
sification, for the primary key (tuple polyinstantiation) can be interpreted as 
the existence of two different entities of the real world (one of which is known 
only at a higher level) . The presence of two tuples with the same key and same 
key classification but that differ for the value and classification of some of its at- 
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tributes can be interpreted as a single real world entity for which different values 
are recorded (corresponding to the different beliefs at different levels). However, 
unfortunately, polyinstantiation quickly goes out of hand, and the execution of 
few operations could result in a database whose semantics does not appear clear 
anymore. Subsequent work tried to establish constraints to maintain semantic 
integrity of the database status [69,75,90]. However, probably because of all the 
complications and semantics confusion that polyinstantiation bears, fine-grained 
multilevel databases did not have much success, and current DBMSs do not sup- 
port element-level classification. Commercial systems (e.g.. Trusted Oracle [66] 
and SYBASE Secure SQL Server) support tuple level classification. 

It is worth noticing that, although polyinstantiation is often blamed to be the 
reason why multilevel relational databases did not have success, polyinstantia- 
tion is not necessarily always bad. Controlled polyinstantiation may, for example, 
be useful to support cover stories [38,49], meaning non-true data whose presence 
in the database is meant to hide the existence of the actual value. Cover stories 
are useful when the fact that a given data is not released is by itself a cause 
of information leakage. For instance, suppose that a subject requires access to 
a hospital’s data and the hospital returns, for all its patients, but for few of 
them, the illness for which they are being cured. Suppose also that HIV never 
appears as an illness value. Observing this, the recipient may infer that it is 
probably the case that the patients for which illness is not disclosed suffer from 
HIV. The hospital could have avoided exposure to such an inference by simply 
releasing a non-true alternative value {cover story) for these patients. Intuitively, 
cover stories are “lies” that the DBMS says to uncleared subjects not to disclose 
(directly or indirectly) the actual values to be protected. We do note that, while 
cover stories are useful for protection, they have raise objections for the possible 
integrity compromises which they may indirectly cause, as low level subjects can 
base their actions on cover stories they believe true. 

A complicating aspects in the support of a mandatory policy at a fine-grained 
level is that the definition of the access class to be associated with each piece 
of data is not always easy [30]. This is the case, for example, of association and 
aggregation requirements, where the classification of a set of values (properties, 
resp.) is higher than the classification of each of the values singularly taken. 
As an example, while names and salaries in an organization may be considered 
Unclassified, the association of a specific salary with an employee’s name can be 
considered Secret (association constraint). Similarly, while the location of a sin- 
gle military ship can be Unclassified, the location of all the ships of a fleet can 
be Secret (aggregation constraint), as by knowing it one could infer that some 
operations are being planned. Proper data classification assignment is also com- 
plicated by the need to take into account possible inference channels [30,47,59]. 
There is an inference channel between a set of data x and a set of data y if, by 
knowing x a user can infer some information on y (e.g., an inference channel can 
exist between an employee’s taxes and her salary). Inference-aware classification 
requires that no information x be classified at a level lower (or incomparable) 
than the level of the information y that can be inferred from it. Capturing and 
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(a) Trusted subject 




(b) Trusted computing base 



Fig. 11. Multilevel DBMSs architectures 



blocking all inference channels is a complex process, also because of the intrinsic 
difficulty of detecting all the semantics relationships between the data that can 
cause inference channels. 

An interesting point that must be taken into account in multilevel database 
systems is the system architecture, which is concerned with the need of confining 
subjects accessing a multilevel database to the data that can be made visible to 
them. This problem comes out in any data system where classification has a finer 
granularity than the stored objects (e.g., multilevel object-oriented systems). 
Two possible approaches are [68]: 

— Trusted subject: data at different levels are stored in a single database (Fig- 
ure 11(a)). The DBMS itself must be trusted to ensure obedience of the 
mandatory policy (i.e., subjects will not gain access to data whose classifi- 
cation they do not dominate). 

— Trusted computing base: data are partitioned in different databases, one for 
each level (Figure 11(b)). In this case only the operating system needs to be 
trusted since every DBMS will be confined to data which subjects using that 
DBMS can access. Decomposition and recovery algorithms must be carefully 
constructed to be correct and efficient [33] . 



4.6 Limitations of Mandatory Policies 

Although mandatory policies, unlike discretionary ones, provide protection 
against indirect information leakages they do not guarantee complete secrecy of 
the information. In fact, secrecy mandatory policies (even with tranquility) con- 
trol only overt channels of information (i.e., flow through legitimate channels); 



Access Control: Policies, Models, and Mechanisms 



161 



they still remain vulnerable to covert channels. Covert channels are channels 
that are not intended for normal communication, but still can be exploited to 
infer information. For instance, consider the request of a low level subject to 
write a non-existent high level file (the operation is legitimate since write-up 
operations are allowed). Now, if the system returns the error, it exposes itself to 
improper leakages due to malicious high level processes creating and destroying 
the high level file to signal information to low processes. However, if the low 
process is not informed of the error, or the system automatically creates the 
file, subjects may not be signalled possible errors made in legitimate attempts 
to write. As another example, consider a low level subject that requires a re- 
source (e.g., CPU or lock) that is busy by a high level subject. The system, by 
not allocating the resource because it is busy, can again be exploited to signal 
information at lower levels (high level processes can module the signal by requir- 
ing or releasing resources). If a low process can see any different result due to 
a high process operation, there is a channel between them. Channels may also 
be enacted without modifying the system’s response to processes. This is, for 
example, the case of timing channels, that can be enacted when it is possible 
for a high process to affect the system’s response time to a low process. With 
timing channels the response that the low process receives is always the same, 
it is the time at which the low process receives the response that communicates 
information. Therefore, in principle, any common resource or observable prop- 
erty of the system state can be used to leak information. Consideration of covert 
channels requires particular care in the design of the enforcement mechanism. 
For instance, locking and concurrency mechanisms must be revised and be prop- 
erly designed [7]. A complication in their design is that care must be taken to 
avoid the policy for blocking covert channels to introduce denials-of-service. For 
instance, a trivial solution to avoid covert channels between high and low level 
processes competing over common resources could be to always give priority to 
low level processes (possibly terminating high level processes). This approach, 
however, exposes the systems to denials-of-service attacks whereby low level 
processes can impede high level (and therefore, presumably, more important) 
processes to complete their activity. 

Covert channels are difficult to control also because of the difficulty of map- 
ping an access control model’s primitive to a computer system [64]. For this 
reason, covert channels analysis is usually carried out in the implementation 
phase, to make sure that the implementation of the model’s primitive is not too 
weak. Covert channel analysis can be based on tracing the information flows 
in programs [31], checking programs for shared resources that can be used to 
transfer information [52], or checking the system clock for timing channels [92]. 
Beside the complexity, the limitation of such solutions is that covert channels 
are found out at the end of the development process, where system changes are 
much more expensive to correct. Interface models have been proposed which at- 
tempt to rule out covert channels analysis in the modeling phase [64,37]. Rather 
than specifying a particular method to enforce security, interface models specify 
restrictions on a system’s input/output that must be obeyed to avoid covert 
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channels. It is then task of the implementor to determine a method for satisfy- 
ing the specifications. A well known principle which formed the basis of interface 
models is the non-interference principle proposed by Goguen and Meseguer [40] . 
Intuitively, non-interference requires that high-level input cannot interfere with 
low-level output. Non-interference constraints enhance the security properties 
that can be formalized and proved in the model; it is however important to 
note that security models do not establish complete security of the system, they 
merely establish security with respect to a model, they can prove only properties 
that have been captured into the model. 

5 Enriching DAC with Mandatory Restrictions 

As we have discussed in the previous section, mandatory policies guarantee bet- 
ter security than discretionary policies, since they can also control indirect infor- 
mation flows. However, their application may result too rigid. Several proposals 
have attempted a combination of mandatory flow control and discretionary au- 
thorizations. We illustrate some of them in this section. 

5.1 The Chinese Wall Policy 

The Chinese Wall [22] policy was introduced as an attempt to balance commer- 
cial discretion with mandatory controls. The goal is to prevent information flows 
which cause conflict of interest for individual consultants (e.g., an individual 
consultant should not have information about two banks or two oil companies). 
However, unlike in the Bell and LaPadula model, access to data is not con- 
strained by the data classifications but by what data the subjects have already 
accessed. The model is based on a hierarchical organization of data objects as 
follows: 

— basic objects are individual items of information (e.g., files), each concerning 
a single corporation; 

— company datasets define groups of objects that refer to a same corporation; 

— conflict of interest classes define company datasets that refer to competing 
corporations. 

Figure 12 illustrates an example of data organization where nine objects of 
four different corporations, namely A,B,C, and D, are maintained. Correspondingly 
four company datasets are defined. The two conflict of interest classes depicted 
define the conflicts between A and B, and between C and D. 

Given the object organization as above, the Chinese Wall policy restricts 
access according to the following two properties [22]: 

Simple security rule A subject s can be granted access to an object o only if 
the object o: 

— is in the same company datasets as the objects already accessed by s, 
that is, “within the Wall”, or 
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Fig. 12. An example of object organization 



— belongs to an entirely different conflict of interest class. 

*-property Write access is only permitted if 

— access is permitted by the simple security rule, and 

— no object can be read which is in a different company dataset than 
the one for which write access is requested, and ii) contains unsanitized 
information. 

The term subject used in the properties is to be interpreted as user (mean- 
ing access restrictions are referred to users). The reason for this is that, unlike 
mandatory policies that control processes, the Chinese Wall policy controls users. 
It would therefore not make sense to enforce restrictions on processes as a user 
could be able to acquire information about organizations that are in conflict of 
interest simply running two different processes. 

Intuitively, the simple security rule blocks direct information leakages that 
can be attempted by a single user, while the *-property blocks indirect infor- 
mation leakages that can occur with the collusion of two or more users. For 
instance, with reference to Figure 12, an indirect improper flow could happen 
if, i) a user reads information from object ObjA-1 and writes it into ObjC-1, 
and subsequently ii) a, different user reads information from ObjC-1 and writes 
it into ObjB-1. 

Clearly, the application of the Chinese Wall policy still has some limitations. 
In particular, strict enforcement of the properties may result too rigid and, like 
for the mandatory policy, there will be the need for exceptions and support of 
sanitization (which is mentioned, but not investigated, in [22]). Also, the enforce- 
ment of the policies requires keeping and querying the history of the accesses. 
A further point to take into consideration is to ensure that the enforcement of 
the properties will not block the system working. For instance, if in a system 
composed of ten users there are eleven company datasets in a conflict of in- 
terest class, then one dataset will remain inaccessible. This aspect was noticed 
in [22], where the authors point out that there must be at least as many users 
as the maximum number of datasets which appear together in a conflict of in- 
terest class. However, while this condition makes the system operation possible, 
it cannot ensure it when users are left completely free choice on the datasets 
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they access. For instance, in a system with ten users and ten datasets, again one 
dataset may remain inaccessible if two users access the same dataset. 

Although the model does have some limitations and drawbacks, the Chinese 
Wall policy represents a good example of dynamic separation of duty constraints 
present in the real world, and has been taken as a reference in the development 
of several subsequent policies and models (see Section 7). 

5.2 Authorization-Based Information Flow Policies 

Other proposals that tried to overcome the vulnerability of discretionary poli- 
cies have worked on complementing authorization control with information flow 
restrictions, interpreting the mandatory and information flow policies [31,55] in 
a discretionary context. 

The work in [19,51] proposes interposing, between programs and the actual 
file system, a protected system imposing further restrictions. In particular, Boe- 
bert and Ferguson [19] forces all files to go through a dynamic linker that com- 
pares the name of the user who invoked the program, the name of the originator 
of the program, and the name of the owner of any data files. If a user invokes 
a program owned by someone else and the program attempts to write the user’s 
files, the dynamic linker will recognize the name mismatch and raise an alarm. 
Karger [51] proposes instead the specification of name restrictions on the files 
that programs can access, and the refusal by the system of all access requests 
not satisfying the given patterns (e.g., a FORTRAN compiler may be restricted 
to read only files with suffix “.for” and to create only files with suffix “.obj” and 
“.lis”). 

McCollum et al. [62] point out data protection requirements that neither the 
discretionary nor the mandatory policies can effectively handle. They propose 
a dissemination control system that maintains access control over one’s data by 
attaching to the data object an access control list (imposing access restrictions) 
that propagates, through subject and object labels, to all objects into which its 
content may flow. Examples of restrictions can be: NOCONTRACT (meaning no 
access to contractors) or NOFORN (no releasable to foreign nationals). By prop- 
agating restrictions and enforcing the control, intuitively, the approach behaves 
like a dynamic mandatory policy; however, explicit restrictions in the access list 
give more flexibility than mandatory security labels. The model also provides 
support for exceptions (the originator of an ACL can allow restrictions to be 
waived) and downgrading (trusted subjects can remove restrictions imposed on 
objects). 

A similar approach appears in [85], which, intuitively, interprets the informa- 
tion flow model of Denning [31] in the discretionary context. In [85] each object 
has two protection attributes: the current access and the potential access. The 
current access attribute describes what operations each user can apply on the 
object (like traditional ACLs). It is a subset of the potential access attribute. 
The potential access attribute describes what operations which users can poten- 
tially apply to the information contained in that object, information that, in the 
future, may be contained in any object and may be of any type. The potential 
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access attributes therefore control information flow. When a new value of some 
object y is produced as a function of objects in x\, . . . ,Xn, then the potential 
access attribute of y is set to be the intersection of the potential access attributes 
of Xi , . . . , Xn • 

Walter et al. [87] propose an interpretation of the mandatory controls within 
the discretionary context. Intuitively, the policy behind this approach, which we 
call strict policy, is based on the same principles as the mandatory policy. Access 
control lists are used in place of labels, and the inclusion relationship between 
sets is used in place of the dominance relationship between labels. Information 
flow restrictions impose that a process can write an object o only if o is protected 
in reading at least as all the objects read by the process up to that point. (An 
object o is at least as protected in reading as another object o' if the set of 
subjects allowed to read o is contained in the set of subjects allowed to read o'.) 
Although the discretionary flexibility of specifying accesses is not lost, the overall 
flexibility is definitely reduced by the application of the strict policy. After having 
read an object o, a process is completely unable to write any object less protected 
in reading than o, even if the write operation would not result in any improper 
information leakage. 

Bertino et al. [14] present an enhancement of the strict policy to introduce 
more flexibility in the policy enforcement. The proposal bases on the observa- 
tion that whether or not some information can be released also depends on the 
procedure enacting the release. A process may access sensitive data and yet not 
release any sensitive information. Such a process should be allowed to bypass the 
restrictions of the strict policy, thus representing an exception. On the other side, 
the information produced by a process may be more sensitive than the informa- 
tion the process has read. An exception should in this case restrict the write 
actions otherwise allowed by the strict policy. Starting from these observations, 
Bertino et al. [14] allow procedures to be granted exceptions to the strict policy. 
The proposal is developed in the context of object-oriented systems, where the 
modularity provided by methods associated with objects allows users to identify 
specific pieces of trusted code for which exceptions can be allowed, and therefore 
provide flexibility in the application of the control. Exceptions can be positive 
or negative. A positive exception overrides a restriction imposed by the strict 
policy, permitting an information flow which would otherwise be blocked. A neg- 
ative exception overrides a permission stated by the strict policy forbidding an 
information flow which would otherwise be allowed. Two kinds of exceptions are 
supported by the model: reply- exceptions and invoke- exceptions. Reply excep- 
tions apply to the information returned by a method. Intuitively, positive reply 
exceptions apply when the information returned by a method is less sensitive 
than the information the method has read. Reply exceptions can waive the strict 
policy restrictions and allow information returned by a method to be disclosed 
to users not authorized to read the objects that the method has read. Invoke 
exceptions apply during a method’s execution, for write operations that the 
method requests. Intuitively, positive invoke exceptions apply to methods that 
are trusted not to leak (through write operations or method invocations) the 
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information they have acquired. The mechanism enforcing the control is based 
on the notion of message filter first introduced by Jajodia and Kogan [46] for 
the enforcement of mandatory policies in object-oriented systems. The message 
filter is a trusted system component that acts as a reference monitor, intercept- 
ing every message exchanged among the objects in a transaction execution to 
guarantee that no unsafe flow takes place. To check whether a write or create 
operation should be blocked, the message Alter in [14] keeps track of the informa- 
tion transmitted between executions and of the users who are allowed to know 
(read) it. A write operation on object o is allowed if, based on the ACLs of the 
objects read and on the exceptions encountered, the information can be released 
to all users who have read privileges on o. 



6 Discretionary Access Control Policies 

In Section 2 we introduced the basic concepts of the discretionary policy by 
illustrating the access matrix (or HRU) model. Although the access matrix still 
remains a framework for reasoning about accesses permitted by a discretionary 
policy, discretionary policies have developed considerably since the access matrix 
was proposed. 

6.1 Expanding Authorizations 

Even early approaches to authorization specifications allowed conditions to be 
associated with authorizations to restrict their validity. Conditions can make the 
authorization validity dependent on the satisfaction of some system predicates 
{system- dependent conditions) like the time or location of access. For instance, 
a condition can be associated with the bank-clerks’ authorization to access ac- 
counts, restricting its application only from machines within the bank building 
and in working hours. Conditions can also constraint access depending on the 
content of objects on which the authorization is defined {content- dependent con- 
ditions). Content-dependent conditions can be used simply as way to determine 
whether or not an access to the object should be granted or as way to restrict 
the portion of the object that can be accessed (e.g., a subset of the tuples in a re- 
lation). This latter option is useful when the authorization object has a coarser 
granularity than the one supported by the data model [29] . Other possible con- 
ditions that can be enforced can make an access decision depend on accesses 
previously executed {history dependent conditions). 

Another feature usually supported even by early approaches is the concept of 
user groups (e.g.. Employees, Programmers, Consultants). Groups can be nested 
and need not be disjoint. Figure 13 illustrates an example of user-group hier- 
archy. Support of groups greatly simplifies management of authorizations, since 
a single authorization granted to a group can be enjoyed by all its members. Later 
efforts moved to the support of groups on all the elements of the authorization 
triple (i.e., subject, object, and action), where, typically, groups are abstractions 
hierarchically organized. For instance, in an operating system the hierarchy can 
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reflect the logical file system tree structure, while in object-oriented system it 
can reflect the class (is-a) hierarchy. Figure 14 illustrates an example of object 
hierarchy. Even actions can be organized hierarchically, where the hierarchy may 
reflect an implication of privileges (e.g., write is more powerful than read [70]) 
or a grouping of sets of privileges (e.g., a “writing privileges” group can be de- 
fined containing write, append, and undo [84]). These hierarchical relationships 
can be exploited i) to support preconditions on accesses (e.g., in Unix a sub- 
ject needs the execute, x, privilege on a directory in order to access the files 
within it), or ii) to support authorization implication, that is, authorizations 
specified on an abstraction apply to all its members. Support of abstractions 
with implications provides a short hand way to specify authorizations, clearly 
simplifying authorization management. As a matter of fact, in most situations 
the ability to execute privileges depends on the membership of users into groups 
or objects into collections: translating these requirements into basic triples of the 
form (user, object, action) that then have to be singularly managed is a consider- 
able administrative burden, and makes it difficult to maintain both satisfactory 
security and administrative efficiency. However, although there are cases where 
abstractions can work just fine, many will be the cases where exceptions (i.e., 
authorizations applicable to all members of a group but few) will need to be sup- 
ported. This observation has brought to the combined support of both positive 
and negative authorizations. Traditionally, positive and negative authorizations 
have been used in mutual exclusion corresponding to two classical approaches 
to access control, namely: 
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Closed policy: authorizations specify permissions for an access (like in the 
HRU model). The closed policy allows an access if there exists a positive 
authorization for it, and denies it otherwise. 

Open policy: (negative) authorizations specify denials for an access. The open 
policy denies an access if there exists a negative authorization for it, and 
allows it otherwise. 

The open policy has usually found application only in those scenarios where 
the need for protection is not strong and by default access is to be granted. 
Most systems adopt the closed policy, which, denying access by default, ensures 
better protection; cases where information is public by default are enforced with 
a positive authorization on the root of the subject hierarchy (e.g.. Public). 

The combined use of positive and negative authorizations was therefore con- 
sidered as a way to conveniently support exceptions. To illustrate, suppose we 
wish to grant an authorization to all members of a group composed of one thou- 
sand users, except to one specific member Bob. In a closed policy approach, we 
would have to express the above requirement by specifying a positive authoriza- 
tion for each member of the group except Bob.^ However, if we combine positive 
and negative authorizations we can specify the same requirement by granting 
a positive authorization to the group and a negative authorization to Bob. 

The combined use of positive and negative authorizations brings now to the 
problem of how the two specifications should be treated: 

— what if for an access no authorization is specified? (incompleteness) 

— what if for an access there are both a negative and a positive authorization? 
(inconsistency) 

Completeness can be easily achieved by assuming that one of either the open 
or closed policy operates as a default, and accordingly access is granted or denied 
if no authorization is found for it. Note that the alternative of explicitly requiring 
completeness of the authorizations is too heavy and complicates administration. 

Conflict resolution is a more complex matter and does not usually have 
a unique answer [48,58]. Rather, different decision criteria could be adopted, 
each applicable in specific situations, corresponding to different policies that can 
be implemented. A natural and straightforward policy is the one stating that 
“the most specific authorization should be the one that prevails”; after all this 
is what we had in mind when we introduced negative authorizations in the first 
place (our example about Bob). Although the most-specific-takes-precedence 
principle is intuitive and natural and likely to fit in many situations, it is not 
enough. As a matter of fact, even if we adopt the argument that the most specific 
authorization always wins (and this may not always be the case) it is not always 
clear what more specific is: 

— what if two authorizations are specified on non-disjoint, but non-hierarchical- 
ly related groups (e.g.. Citizens and CS-Dept in Figure 13)? 

^ In an open policy scenario, the dual example of all users, but a few, who have to be 
denied an access can be considered. 
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— what if for two authorizations the most specific relationship appear reversed 
over different domains? For instance, consider authorizations (CS-Faculty, 
read+, mail) and (CS-Dept, read—, personal); the first has a more specific 
subject, while the second has a more specific object (see Figures 13 and 14). 

A slightly alternative policy on the same line as the most specific policy 
is what in [48] is called most- specific- along- a-path-takes-precedence. This policy 
considers an authorization specified on an element x as overriding an autho- 
rization specified on a more general element y only for those elements that are 
members of y because of x. Intuitively, this policy takes into account the fact 
that, even in the presence of a more specific authorization, the more general 
authorization can still be applicable because of other paths in the hierarchy. 
For instance, consider the group hierarchy in Figure 13 and suppose that for 
an access a positive authorization is granted to Public while a negative autho- 
rization is granted to CS-Dept. What should we decide for George? On the one 
side, it is true that CS-Dept is more specific than Public; on the other side, 
however, George belongs to Eng-Dept, and for Eng-Dept members the posi- 
tive authorization is not overridden. While the most-specific-takes-precedence 
policy would consider the authorization granted to Public as being overridden 
for George, the most-specific-along-a-path considers both authorizations as ap- 
plicable to George. Intuitively, in the most-specific-along-a-path policy, an au- 
thorization propagates down the hierarchy until overridden by a more specific 
authorization [35]. 

The most specific argument does not always apply. For instance, an organi- 
zation may want to be able to state that consultants should not be given access 
to private projects, no exceptions allowed. However, if the most specific policy is 
applied, any authorization explicitly granted to a single consultant will override 
the denial specified by the organization. To address situations like this, some 
approaches proposed adopting explicit priorities . In ORION [70] , authorizations 
are classified as strong or weak: weak authorizations override each other based on 
the most-specific policy, and strong authorizations override weak authorizations 
(no matter their specificity) and cannot be overridden. Given that strong autho- 
rizations must be certainly obeyed, they are required to be consistent. However, 
this requirement may be not always be enforceable. This is, for example, the 
case where groupings are not explicitly defined but depend on the evaluation of 
some conditions (e.g., “all objects owned by Tom”, “all objects created before 
1/1/01”). Also, while the distinction between strong and weak authorizations 
is convenient in many situations and, for example, allows us to express the or- 
ganizational requirement just mentioned, it is limited to two levels of priority, 
which may not be enough. Many other conflict resolution policies can be applied. 
Some approaches, extending the strong and weak paradigm, proposed adopting 
explicit priorities', however, these solutions do not appear viable as the autho- 
rization specifications may result not always clear. Other approaches (e.g., [84]) 
proposed making authorization priority dependent on the order in which au- 
thorizations are listed (i.e., the authorizations that is encountered first applies). 
This approach, however, has the drawback that granting or removing an au- 
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— Denials -take-precedence: negative authorizations take precedence (satisfies the “fail 
safe principle”) 

— Most-specific-takes-precedence the authorization that is “more specific” w.r.t. 
a partial order (i.e., hierarchy) wins 

— Most-specific-along-a-path-takes-precedenee: the authorization that is “more spe- 
cific” wins only on the paths passing through it. Intuitively, an authorization 
propagates down a hierarchy until overridden by a more specific authorization. 

— Strong/weak: authorizations are classified as strong or weak: weak authorizations 
override each other based on the most-specific policy, and strong authorizations 
override weak authorizations (no matter their specificity). Strong authorizations 
are therefore required to be consistent. 

— Priority level: each authorization is associated with a priority level, the authoriza- 
tion with the highest priority wins. 

— Positional: the priority of the authorizations depends on the order in which they 
appear in the authorization list. 

— Grantor-dependent: the priority of the authorizations depends on who granted 
them. 

— Time- dependent the priority of the authorizations depends on the time at they 
have been granted (e.g., more recent wins) 



Fig. 15. Examples of conflict resolution policies 



thorization requires inserting the authorization in the proper place in the list. 
Beside the administrative burden put on the administrator (who, essentially, has 
to explicitly solve the conflicts when deciding the order), specifying authoriza- 
tions implies explicitly writing the ACL associated with the object, and may 
impede delegation of administrative privileges. Other possible ways of defining 
priorities, and therefore solving conflicts, can make the authorization’s priority 
dependent on the time at which the authorizations was granted (e.g., more re- 
cent authorizations prevails) or on priorities between the grantors . For instance, 
authorizations specified by an employee may be overridden by those specified by 
his supervisor; the authorizations specified by an object’s owner may override 
those specified by other users to whom the owner has delegated administrative 
authority. 

As it is clear from this discussion, different approaches can be taken to deal 
with positive and negative authorizations. Also, if it is true that some solutions 
may appear more natural than others, none of them represents “the perfect 
solution” . Whichever approach we take, we will always And one situation for 
which it does not fit. Also, note that different conflict resolution policies are 
not mutually exclusive. For instance, one can decide to try solving conflicts 
with the most-specific-takes-precedence policy first, and apply the denials-take- 
precedence principle on the remaining conflicts (i.e., conflicting authorizations 
that are not hierarchically related). 

The support of negative authorizations does not come for free, and there 
is a price to pay in terms of authorization management and less clarity of the 
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specifications. However, the complications brought by negative authorizations 
are not due to negative authorizations themselves, but to the different semantics 
that the presence of permissions and denials can have, that is, to the complex- 
ity of the different real world scenarios and requirements that may need to be 
captured. There is therefore a trade-off between expressiveness and simplicity. 
For this reason, most current systems adopting negative authorizations for ex- 
ception support impose specific conflict resolution policies, or support a limited 
form of conflict resolution. For instance, in the Apache server [6], authorizations 
can be positive and negative and an ordering ( “deny,allow” or “allow, deny”) 
can be specified dictating how negative and positive authorizations are to be in- 
terpreted. In the “deny, allow” order, negative authorizations are evaluated first 
and access is allowed by default (open policy). Any client that does not match 
a negative authorization or matches a positive authorization is allowed access. In 
the “allow, deny” order, the positive authorizations are evaluated first and access 
is denied by default (closed policy). Any client that does not match a positive 
authorization or does match a negative authorization will be denied access. 

More recent approaches are moving towards the development of flexible 
frameworks with the support of multiple conflict resolution and decision policies. 
We will examine them in Section 8. 

Other advancements in authorization specification and enforcement have 
been carried out with reference to specific applications and data mod- 
els. For instance, authorization models proposed for object-oriented systems 
(e.g., [2,35,71]) exploit the encapsulation concept, meaning the fact that access 
to objects is always carried out through methods (read and write operations 
being primitive methods). In particular, users granted authorizations to invoke 
methods can be given the ability to successfully complete them, without need to 
have the authorizations for all the accesses that the method execution entails. 
For instance, in OSQL, each derived function (i.e., method) can be specified as 
supporting static or dynamic authorizations [2] . A dynamic authorization allows 
the user to invoke the function, but its successful completion requires the user to 
have the authorization for all the calls the function makes during its execution. 
With a static authorization, calls made by the function are checked against the 
creator of the function, instead of those of the calling user. Intuitively, static 
authorizations behave like the setuid (set user id) option, provided by the Unix 
operating system that, attached to a program (e.g., Ipr) implies that all access 
control checks are to be performed against the authorizations of the program’s 
owner (instead of those of the caller as it would otherwise be) . A similar feature 
is also proposed in [71], where each method is associated with a principal, and 
accesses requested during a method execution are checked against the autho- 
rization of the method’s principal. Encapsulation is also exploited by the Java 2 
security model [83] where authorizations can be granted to code, and requests 
to access resources are checked against the authorizations of the code directly 
attempting the access. 
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6.2 Temporal Authorizations 

Bertino et al. [13] propose extending authorizations with temporal constraints 
and extending authorization implication with time-based reasoning. Authoriza- 
tions have associated a validity specified by a temporal expression identifying the 
instants in which the authorization applies. The temporal expression is formed by 
a periodic expression (e.g., 9 a.m. to 1 p.m. on Working-days, identifying 
the periods from 9a.m. to 1p.m. in all days excluding weekends and vacations), 
and a temporal interval bounding the scope of the periodic expression (e.g., 
[2/1997,8/1997], restricting the specified periods to those between February 
and August 1997). The model allows also the specification of derivation rules, ex- 
pressing temporal dependencies among authorizations, that allow the derivation 
of new authorizations based on the presence or absence of other authorizations 
in specific periods of time. For instance, it is possible to specify that two users, 
working on the same project, must receive the same authorizations on given 
objects, or that a user should receive the authorization to access an object in 
certain periods, only if nobody else was ever authorized to access the same ob- 
ject in any instant within those periods. Like authorizations, derivation rules are 
associated with a temporal expression identifying the instants in which the rule 
applies. A derivation rule is a triple (Ltb,te1 , P, A (op) A), where interval 
[tb,tel and period P represent the temporal expression, A is the authorization 
to be derived, A a is boolean formula of authorizations on which derivation is 
based, and OP is one of the following operators: whenever, ASLONGAS, upon. 
The three operators correspond to different temporal relationships between au- 
thorizations on which derivation can work, and have the following semantics: 

— WHENEVER derives A for each instant in ( Ub,te1 ,P) for which A is valid. 

— ASLONGAS derives A for each instant in ([tb,te1 ,P) such that A has been 
“continuously” valid in (Ltf,,te'] ,P) ■ 

— UPON derives A from the first instant in ( [tf,, tel ,P) for which A is valid up 
to te- 

A graphical representation of the semantics of the different temporal opera- 
tors is given in Figure 16. Intuitively, whenever captures the usual implication 
of authorizations. For instance, a rule can state that summer-staff can read a doc- 
ument for every instance (i.e., whenever) in the summer of year 2000 in which 
regular-staff can read it. ASLONGAS works in a similar way but stops the deriva- 
tion at the first instant in which the boolean formula on which derivation works 
is not satisfied. For instance, a rule can state that regular-staff can read a doc- 
ument every working day in year 2000 until the first working day in which (i.e., 
ASLONGAS) summer-staff is allowed for that. Finally, upon works like a trigger. 
For instance, a rule can state that Ann can read pay-checks each working day 
starting from the first working day in year 2000 in which (i.e., upon) Tom can 
write pay-checks. 

The enforcement mechanism is based on a translation of temporal authoriza- 
tions and derivation rules into logic programs (Datalog programs with negation 
and periodicity and order constraints) . The materialization of the logic program 
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Legend 

R=([tb,te],P,A <OP>A) 

I I instants denoted by P 

validity of formulaA 



derivability of A if R is an ASLONGAS rule 
derivability of A if R is an UPON rule 
derivability of A if R is a WHENEVER rule 



Fig. 16. Semantics of the different temporal operators [13] 



guarantees efficient access. The model is focussed on time-based constraints and 
reasoning and allows expressing authorization relationships and derivation not 
covered in other models. However, it does not address the enforcement of dif- 
ferent implication and conflict resolution policies (conflicts between permissions 
and denials are solved according to the denials-take-precedence policy). 

6.3 A Calculus for Access Control 

Abadi et al. [1] present a calculus for access control that combines authentication 
(i.e., identity check) and authorization control, taking also into account possible 
delegation of privileges among parties. The calculus is based on the notion of 
principals. Principals are sources of requests and make statements (e.g., “read 
file tmp”). Principals can be either simple (e.g., users, machines, and commu- 
nication channels) or composite. Composite principals are obtained combining 
principals by means of constructors that allow to capture groups and delega- 
tions. a Principals can be as follows [1]: 

— Users and machines. 

— Channels, such as input devices and cryptographic channels. 

— Conjunction of principals , of the form A A B. A request ^from A A B is 
a request that both A and B make (it is not necessary that the request be 
made in concert). 

— Croups, define groups of principals, membership of principal Pi in group Gi 
is written Pi => Gi. Disjunction AV B denotes a group composed only of 
A and B. 
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— Principals in roles, of the form A as R. The principal A may adopt the role R 
and act under the name “A as i?” when she wants to diminish her powers, 
in particular as protection against blunders.® 

— Principals on behalf of principals, of the form A for B. The principal A may 
delegate authority to B, and B can then act on her behalf, using the iden- 
tity B for A. In most cases, ^ is a user delegating to a machine B-, delegation 
can also occur between machines. 

— Principals speaking for other principals, of the form A o B, denoting that 
B speaks on behalf of A, but not necessarily with a proof that A has delegated 
authority to B. 

The process of determining whether a request from a principal should be 
granted or denied is based on a modal logic that extends the algebra of principals 
and serves as a basis for different algorithms and protocols. Intuitively, a request 
on an object will be granted if it is authorized according to the authorizations 
stated in the ACL of the object and the implication relationships and delegations 
holding among principals. 

6.4 Administrative Policies 

Administrative policies determine who is authorized to modify the allowed ac- 
cesses. This is one of the most important, and probably least understood, aspect 
of access controls. In multilevel mandatory access control the allowed accesses 
are determined entirely on basis of the security classification of subjects and 
objects. Security levels are assigned to users by the security administrator. Se- 
curity levels of objects are determined by the system on the basis of the levels 
of the users creating them. The security administrator is typically the only one 
who can change security levels of subjects and objects. The administrative pol- 
icy is therefore very simple. Discretionary access control permits a wide range 
of administrative policies. Some of these are described below. 

— Centralized: A single authorizer (or group) is allowed to grant and revoke 
authorizations to the users. 

— Hierarchical: A central authorizer is responsible for assigning administrative 
responsibilities to other administrators. The administrators can then grant 
and revoke access authorizations to the users of the system. Hierarchical 
administration can be applied, for example, according to the organization 
chart. 

~ Cooperative: Special authorizations on given resources cannot be granted by 
a single authorizer but need cooperation of several authorizers. 

® Note that there is a difference in the semantics assigned to roles in [1] and in role- 
based access control model (see Section 7). In [1] a principal’s privileges always 
diminish when the principal takes on some role; also an implication relationship is 
enforced allowing a principal P to use authorizations granted to any principal of the 
form P as R. 
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— Ownership: Each object is associated with an owner, who generally coincides 
with the user who created the object. Users can grant and revoke authoriza- 
tions on the objects they own. 

— Decentralized: Extending the previous approaches, the owner of an object 
(or its administrators) can delegate other users the privilege of specifying 
authorizations, possibly with the ability of further delegating it. 

Decentralized administration is convenient since it allows users to delegate 
administrative privileges to others. Delegation, however, complicates the autho- 
rization management. In particular, it becomes more difficult for users to keep 
track of who can access their objects. Furthermore, revocation of authorizations 
becomes more complex. There are many possible variations on the way decentral- 
ized administration works, which may differ in the way the following questions 
are answered. 

— what is the granularity of administrative authorizations? 

— can delegation be restricted, that is, can the grantor of an administrative 
authorization impose restrictions on the subjects to which the recipient can 
further grant the authorization? 

— who can revoke authorizations? 

— what about authorizations granted by the revokee? 

In general, existing decentralized policies allow users to grant administra- 
tion for a specific privilege (meaning a given access on a given object). They 
do not allow, however, to put constraints on the subjects to which the recipi- 
ent receiving administrative authority can grant the access. This feature could, 
however, result useful. For instance, an organization could delegate one of its 
employees to granting access to some resources constraining the authorizations 
she can grant to employees working within her laboratory. Usually, authoriza- 
tions can be revoked only by the user who granted them (or, possibly, by the 
object’s owner). When an administrative authorization is revoked, the problem 
arises of dealing with the authorizations specified by the users from whom the 
administrative privilege is being revoked. For instance, suppose that Ann gives 
Bob the authorization to read Filel and gives him the privilege of granting this 
authorization to others (in some systems, such capability of delegation is called 
grant option [42]). Suppose then that Bob grants the authorization to Chris, 
and susequently Ann revokes the authorization from Bob. The question now is: 
what should happen to the authorization that Chris has received? To illustrate 
how revocation can work it is useful to look at the history of System R [42] . In 
the System R authorization model, users creating a table can grant other users 
access privileges on it. Authorizations can be granted with the grant-option. If 
a user receives the authorization for an access with the grant-option she can 
grant the access (and the grant option on it) to others. Intuitively, this intro- 
duces a chain of authorizations. The original System R policy, which we call 
(time-based) cascade revocation, adopted the following semantics for revocation: 
when a user is revoked the grant option on an access, all authorizations that 
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Fig. 17. Example of the original System-R, time-based cascade revocation 



she granted and could not have been granted had the revoked authorization not 
been present, should also be (recursively) deleted. The revocation is recursive 
since it may, in turn, cause other authorizations to be deleted. More precisely, 
let AUTH he the initial authorization state and Gi, . . . ,Gn be a sequence of 
grant requests (history) that produced authorization state AUTH'. The revo- 
cation of a grant Gk should result in authorization state AUTH" as if Gk had 
never been granted, that is, resulting from history Gi, . . . , Gfc_i, Gk+i, ■ ■ ■ , Gn- 
Enforcement of this revocation semantics requires to keep track oii) who granted 
which authorization, and ii) the time at which the authorization was granted. 
To illustrate, consider the sequence of grant operations pictured in Figure 17(a), 
referred to the delegation of a specific privilege. Here, nodes represent users, 
and arcs represent the granting of a specific access from one user to another. 
The label associated with the arc states the time at which the authorization 
was granted and whether the grant option was granted as well. For instance, 
Ann granted the authorization, with the grant option, to Bob at time 20, and to 
Chris at time 30. Suppose now that Bob revokes the authorization he granted to 
David. According to the revocation semantics to be enforced, the authorization 
that David granted to Ellen must be deleted as well, since it was granted at 
time 50 when, had David not hold the authorizations being revoked, the grant 
request would have been denied. Consequently, and for the same reasoning, the 
two authorizations granted by Ellen also need to be deleted, resulting in the 
authorization state of Figure 17(b). 

Although the time-based cascade revocation has a clean semantics, it is not 
always accepted. Deleting all authorizations granted in virtue of an authorization 
that is being revoked is not always wanted. In many organizations, the authoriza- 
tions that users possess are related to their particular tasks or functions within 
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the organization. Suppose there is a change in the task or function of a user (say, 
because of a job promotion). This change may imply a change in the responsibili- 
ties of the user and therefore in her privileges. New authorizations will be granted 
to the user and some of her previous authorizations will be revoked. Applying a 
recursive revocation will result in the undesirable effect of deleting all authoriza- 
tions the revokee granted and, recursively, all the authorizations granted through 
them, which then will need to be re-issued. Moreover, all application programs 
depending on the revoked authorizations will be invalidated. An alternative form 
of revocation was proposed in [15], where non-cascade revocation is introduced. 
Instead of deleting all the authorizations granted by the revokee in virtue of the 
authorizations being revoked, non-recursive revocation re-specifies them to be 
under the authority of the revoker, which can then retain or selectively delete 
them. The original time-based revocation policy of System R, was changed to 
not consider time anymore. In SQL:1999 [28] revocation can be requested with 
or without cascade. Cascade revocation recursively deletes authorizations if the 
revokee does not hold anymore the grant option for the access. However, if the 
revokee still holds the grant option for the access, the authorizations she granted 
are not deleted (regardless of time they were granted). For instance, with ref- 
erence to Figure 17(a), the revocation by Bob of the authorization granted to 
David, would only delete the authorization granted to David by Bob. Ellen’s 
authorization would still remain valid since David still holds the grant option 
of the access (because of the authorization from Chris). With the non cascade 
option the system rejects the revoke operation if its enforcement would entail 
deletion of other authorizations beside the one for which revocation is requested. 

6.5 Integrity Policies 

In Section 4.4 we illustrated a mandatory policy (namely Biba’s model) for 
protecting information integrity. Biba’s approach, however, suffers of two major 
drawbacks: i) the constraints imposed on the information flow may result too 
restrictive, and ii) it only controls integrity intended as the prevention of a flow 
of information from low integrity objects to high integrity objects. However, this 
notion of one-directional information flow in a lattice captures only a small part 
of the data integrity problem [74]. 

Integrity is concerned with ensuring that no resource (including data and 
programs®) has been modified in an unauthorized or improper way and that the 
data stored in the system correctly reflect the real world they are intended to 
represent (i.e., that users expect). Integrity preservation requires prevention of 
frauds and errors, as the term “improper” used above suggests: violations to 
data integrity are often enacted by legitimate users executing authorized actions 
but misusing their privileges. 

Any data management system today has functionalities for ensuring in- 
tegrity [8]. Basic integrity services are, for example, concurrency control (to 

® Programs improperly modified can fool the access control and bypass the system 
restrictions, thus violating the secrecy and/or integrity of the data (see Section 3). 
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ensure correctness in case of multiple processes concurrently accessing data) 
and recovery techniques (to reconstruct the state of the system in the case of 
violations or errors occur). Database systems also support the definition and 
enforcement of integrity constraints, that define the valid states of the database 
constraining the values that it can contain. Also, database systems support the 
notion of transaction, which is a sequence of actions for which the ACID prop- 
erties must be ensured, where the acronym stands for: Atomicity (a transaction 
is either performed in its entirety or not performed at all); Consistency (a trans- 
action must preserve the consistency of the database); Isolation (a transaction 
should not make its updates visible to other transactions until it is committed); 
and Durability (changes made by a transaction that has committed must never 
be lost because of subsequent failures) . 

Although rich, the integrity features provided by database management sys- 
tems are not enough: they are only specified with respect to the data and their 
semantics, and do not take into account the subjects operating on them. There- 
fore, they can only protect against obvious errors in the data or in the system 
operation, and not against misuses by subjects [23]. The task of a security pol- 
icy for integrity is therefore to fill this gap and control data modifications and 
procedure executions with respect to the subjects performing them. An attempt 
in this respect is represented by the Clark and Wilson’s proposal [25] , where the 
following four basic criteria for achieving data integrity are defined. 

1. Authentication. The identity of all users accessing the system must be prop- 
erly authenticated (this is an obvious prerequisite for correctness of the con- 
trol, as well as for establishing accountability). 

2. Audit. Modifications should be logged for the purpose of maintaining an 
audit log that records every program executed and the user who executed 
it, so that changes could be undone. 

3. Well-formed transactions Users should not manipulate data arbitrarily 
but only in constrained ways that ensure data integrity (e.g., double en- 
try bookkeeping in accounting systems) . A system in which transactions are 
well-formed ensures that only legitimate actions can be executed. In addi- 
tion, well-formed transactions should provide logging and serializability of 
resulting subtransactions in a way that concurrency and recovery mecha- 
nisms can be established. 

4. Separation of duty The system must associate with each user a valid set 
of programs to be run. The privileges given to each user must satisfy the 
separation of duty principle. Separation of duty prevents authorized users 
from making improper modifications, thus preserving the consistency of data 
by ensuring that data in the system reflect the real world they represent. 

While authentication and audit are two common mechanisms for any access 
control system, the latter two aspects are peculiar to the Clark and Wilson 
proposal. 

The definition of well-formed transaction and the enforcement of separation 
of duty constraints is based on the following concepts. 
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Cl: All IVPs must ensure that all GDIs are in a valid state when the IVP is run. 

C2: All TPs must be certified to be valid (i.e., preserve validity of GDIs’ state) 

C3: Assignment of TPs to users must satisfy separation of duty 

C4: The operations of TPs must be logged 

C5: TPs execute on UDIs must result in valid GDIs 

El: Only certified TPs can manipulate GDIs 

E2: Users must only access GDIs by means of TPs for which they are authorized 
E3: The identity of each user attempting to execute a TP must be authenticated 
E4: Only the agent permitted to certify entities can change the list of such entities 
associated with other entities 



Fig. 18. Clark and Wilson integrity rules 



— Constrained Data Items. GDIs are the objects whose integrity must be safe- 
guarded. 

— Unconstrained Data Items. UDIs are objects that are not covered by the 
integrity policy (e.g., information typed by the user on the keyboard). 

— Integrity Verification Procedures. IVPs are procedures meant to verify that 
GDIs are in a valid state, that is, the IVPs confirm that the data conforms 
to the integrity specifications at the time the verification is performed. 

— Transformation Procedures. TPs are the only procedures (well-formed pro- 
cedures) that are allowed to modify GDIs or to take arbitrary user input and 
create new GDIs. TPs are designed to take the system from one valid state 
to the next 

Intuitively, IVPs and TPs are the means for enforcing the well-formed trans- 
action requirement: all data modifications must be carried out through TPs, and 
the result must satisfy the conditions imposed by the IVPs. 

Separation of duty must be taken care of in the definition of authorized op- 
erations. In the context of the Clark and Wilson’s model, authorized operations 
are specified by assigning to each user a set of well-formed transactions that she 
can execute (which have access to constraint data items) . Separation of duty re- 
quires the assignment to be defined in a way that makes it impossible for a user 
to violate the integrity of the system. Intuitively, separation of duty is enforced 
by splitting operations in subparts, each to be executed by a different person (to 
make frauds difficult). For instance, any person permitted to create or certify 
a well-formed transaction should not be able to execute it (against production 
data). 

Figure 18 summarizes the nine rules that Clark and Wilson presented for 
the enforcement of system integrity. The rules are partitioned into two types: 
certification (C) and enforcement (E). Certification rules involve the evaluation 
of transactions by an administrator, whereas enforcement is performed by the 
system. 

The Clark and Wilson’s proposal outlines good principles for controlling in- 
tegrity. However, it has limitations due to the fact that it is far from formal and 
it is unclear how to formalize it in a general setting. 
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7 Role-Based Access Control Policies 

Role-based access control (RBAC) is an alternative to traditional discretionary 
(DAC) and mandatory access control (MAC) policies that is attracting increas- 
ing attention, particularly for commercial applications. The main motivation 
behind RBAC is the necessity to specify and enforce enterprise-specific security 
policies in a way that maps naturally to an organization’s structure. In fact, 
in a large number of business activities a user’s identity is relevant only ^from 
the point of view of accountability. For access control purposes it is much more 
important to know what a user’s organizational responsibilities are, rather than 
who the user is. The conventional discretionary access controls, in which indi- 
vidual user ownership of data plays such an important part, are not a good 
fit. Neither are the full mandatory access controls, in which users have security 
clearances and objects have security classifications. Role-based access control 
tries to fill in this gap by merging the flexibility of explicit authorizations with 
additionally imposed organizational constraints. 

7.1 Named Protection Domain 

The idea behind role-based access control is grouping privileges (i.e., authoriza- 
tions). The first work proposing collecting privileges for authorization assignment 
is probably the work by Baldwin [9] , where the concept of named protection do- 
main (NPD) is introduced as a way to simplify security management in an 
SQL-based framework. Intuitively, a named protection domain identifies a set 
of privileges (those granted to the NPD) needed to accomplish a well-defined 
task. For instance, in a bank organization, an NPD AccountsJleceivable can 
be defined to which all the privileges needed to perform the account-receivable 
task are granted. NPD can be granted to users as well as to other NPDs, thus 
forming a chain of privileges. The authorization state can be graphically repre- 
sented as a directed acyclic graph where nodes correspond to privileges, NPDs, 
and users, while arcs denote authorization assignments. An example of privilege 
graph is illustrated in Figure 19, where three NPDs (AccountsJleceivable, 
Accounts Payable, and Accounts_Supervisor) and the corresponding privi- 
leges are depicted. Users can access objects only by activating NPDs holding 
privileges on them. Users can only activate NPDs that have been directly or 
indirectly assigned to them. For instance, with reference to Figure 19, Bob can 
activate any of three NPDs, thus acquiring the corresponding privileges. To en- 
force least privilege, users are restricted to activate only one NPD at the time. 
NPDs can also be used to group users. For instance, a NPD named Employees 
can be defined which corresponds to the set of employees of an organization. 
NPDs correspond to the current concept of roles in SQL:1999 [28]. 

7.2 Role-Based Policies 

Role-based policies regulate the access of users to the information on the basis 
of the organizational activities and responsibility that users have in a system. 
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Although different proposals have been made (e.g., [3,36,45,56,67,76,80]), the 
basic concepts are common to all approaches. Essentially, role based policies 
require the identification of roles in the system, where a role can be defined as 
a set of actions and responsibilities associated with a particular working activity. 
The role can be widely scoped, reflecting a user’s job title (e.g., secretary), or 
it can be more specific, reflecting, for example, a task that the user needs to 
perform (e.g., order_processing). Then, instead of specifying all the accesses 
each users is allowed to execute, access authorizations on objects are specified 
for roles. Users are then given authorizations to adopt roles (see Figure 20). 
The user playing a role is allowed to execute all accesses for which the role is 
authorized. In general, a user can take on different roles on different occasions. 
Also the same role can be played by several users, perhaps simultaneously. Some 
proposals for role-based access control (e.g., [76,80]) allow a user to exercise 
multiple roles at the same time. Other proposals (e.g., [28,48]) limit the user to 
only one role at a time, or recognize that some roles can be jointly exercised while 
others must be adopted in exclusion to one another. It is important to note the 
difference between groups (see Section 6) and roles: groups define sets of users 
while roles define sets of privileges. There is a semantic difference between them: 
roles can be “activated” and “deactivated” by users at their discretion, while 
group membership always applies, that is, users cannot enable and disable group 
memberships (and corresponding authorizations) at their will. However, since 
roles can be defined which correspond to organizational figures (e.g., secretary, 
chair, and faculty), a same “concept” can be seen both as a group and as a role. 

The role-based approach has several advantages. Some of these are discussed 
below. 

Authorization management Role-based policies benefit from a logical inde- 
pendence in specifying user authorizations by breaking this task into two 
parts: i) assignement of roles to users, and ii) assignement of authorizations 
to access objects to roles. This greatly simplifies the management of the 
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Fig. 20. Role-based access control 



security policy: when a new user joins the organization, the administrator 
only needs to grant her the roles corresponding to her job; when a user’s 
job changes, the administrator simply has to change the roles associated 
with that user; when a new application or task is added to the system, the 
administrator needs only to decide which roles are permitted to execute it. 

Hierarchical roles In many applications there is a natural hierarchy of roles, 
based on the familiar principles of generalization and specialization. Fig- 
ure 21 illustrates an example of role hierarchy: each role is represented as 
a node and there is an arc between a specialized role and its generaliza- 
tion. The role hierarchy can be exploited for authorization implication. For 
instance, authorizations granted to roles can be propagated to their spe- 
cializations (e.g., the secretary role can be allowed all accesses granted to 
adm_staf f ). Authorization implication can also be enforced on role assign- 
ments, by allowing users to activate all generalizations of the roles assigned 
to them (e.g., a user allowed to activate secretary will also be allowed to 
activate role adm_staf f ). Authorization implication has the advantage of fur- 
ther simplifying authorization management. Note however that not always 
implication may be wanted, as propagating all authorizations is contrary to 
the least privilege principle. The hierarchy has also been exploited in [77] 
for the definition of administrative privileges: beside the hierarchy of orga- 
nizational roles, an additional hierarchy of administrative roles is defined; 
each administrative role can be given authority over a portion of the role 
hierarchy. 

Least privilege Roles allow a user to sign on with the least privilege required 
for the particular task she needs to perform. Users authorized to power- 
ful roles do not need to exercise them until those privileges are actually 
needed. This minimizes the danger of damage due to inadvertent errors, 
Trojan Horses, or intruders masquerading as legitimate users. 

Separation of duties Separation of duties refer to the principle that no user 
should be given enough privileges to misuse the system on their own. For 
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instance, the person authorizing a paycheck should not be the same person 
who can prepare them. Separation of duties can be enforced either statically 
(by defining conflicting roles, that is, roles which cannot be executed by 
the same user) or dynamically (by enforcing the control at access time) . An 
example of dynamic separation of duty restriction is the two-person rule. 
The first user to execute a two-person operation can be any authorized user, 
whereas the second user can be any authorized user different ^from the 
first [79]. 

Constraints enforcement Roles provide a basis for the specification and en- 
forcement of further protection requirements that real world policies may 
need to express. For instance, cardinality constraints can be specified, that 
restrict the number of users allowed to activate a role or the number of roles 
allowed to exercise a given privilege. The constraints can also be dynamic, 
that is, be imposed on roles activation rather than on their assignment. For 
instance, while several users may be allowed to activate role chair, a further 
constraint can require that at most one user at a time can activate it. 

Role-based policies represent a promising direction and a useful paradigm 
for many commercial and government organizations. However, there is still some 
work to be done to cover all the different requirements that real world scenarios 
may present. For instance, the simple hierarchical relationship as intended in 
current proposals may not be sufficient to model the different kinds of relation- 
ships that can occur. For example, a secretary may need to be allowed to write 
specific documents on behalf of her manager, but neither role is a specialization 
of the other. Different ways of propagating privileges (delegation) should then 
be supported. Similarly, administrative policies should be enriched. For instance, 
the traditional concept of ownership may not apply anymore: a user does not 
necessarily own the objects she created when in a given role. Also, users’ identi- 
ties should not be forgotten. If it true that in most organizations, the role (and 
not the identity) identifies the privileges that one may execute, it is also true 
that in some cases the requestor’s identity needs to be considered even when 
a role-based policy is adopted. For instance, a doctor may be allowed to specify 
treatments and access files but she may be restricted to treatments and files 
for her own patients, where the doctor-patient relationships is defined based on 
their identity. 
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8 Advanced Access Control Models 

Throughout the chapter we investigated different issues concerning the devel- 
opment of an access control system, discussing security principles, policies, and 
models proposed in the literature. In this section we illustrate recent proposals 
and ongoing work addressing access control in emerging applications and new 
scenarios. 

8.1 Logic-Based Authorization Languages 

As discussed in Section 6, access control systems based only on the closed policy 
clearly have limitations. The support of abstractions and authorization implica- 
tions along them and the support of positive and negative authorizations provide 
more flexibility in the authorization specifications. As we have seen, several ac- 
cess control policies can be applied in this context (e.g., denials-take-precedence, 
most-specific-takes-precedence, strong and weak) and have been proposed in 
the literature. Correspondingly, several authorization models have been formal- 
ized and access control mechanisms enforcing them implemented. However, each 
model, and its corresponding enforcement mechanism, implements a single speci- 
fied policy, which is in fact built into the mechanism. As a consequence, although 
different policy choices are possible in theory, each access control system is in 
practice bound to a specific policy. The major drawback of this approach is that 
a single policy simply cannot capture all the protection requirements that may 
arise over time. As a matter of fact, even within a single system: 

~ different users may have different protection requirements; 

— a single user may have different protection requirements on different objects; 

— protection requirements may change over time. 

When a system imposes a specific policy on users, they have to work within 
the confines imposed by the policy. When the protection requirements of an 
application are different from the policy built into the system, in most cases, 
the only solution is to implement the policy as part of the application code. 
This solution, however, is dangerous from a security viewpoint since it makes 
the tasks of verification, modification, and adequate enforcement of the policy 
difficult. 

Recent proposals have worked towards languages and models able to express, 
in a single framework, different access control policies, to the goal of providing 
a single mechanism able to enforce multiple policies. Logic-based languages, for 
their expressive power and formal foundations, represent a good candidate. The 
first work investigating logic-languages for the specification of authorizations is 
the work by Woo and Lam [91]. Their proposal makes the point for the need of 
flexibility and extensibility in access specifications and illustrates how these ad- 
vantages can be achieved by abstracting from the low level authorization triples 
and adopting a high level authorization language. Their language is essentially 
a many-sorted first-order language with a rule construct, useful to express autho- 
rization derivations and therefore model authorization implications and default 
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decisions (e.g., closed or open policy). The use of a very general language, which 
has almost the same expressive power of first order logic, allows the expression of 
different kinds of authorization implications, constraints on authorizations, and 
access control policies. However, as a drawback, authorization specifications may 
result difficult to understand and manage. Also, the trade-off between expres- 
siveness and efficiency seems to be strongly unbalanced: the lack of restrictions 
on the language results in the specification of models which may not even be 
decidable and therefore will not be implement able. As noted in [48], Woo and 
Lam’s approach is based on truth in extensions of arbitrary default theories, 
which is known, even in the propositional case to be NP-complete, and in the 
first order case, is worse than undecidable. 

Starting from these observations, Jajodia et al. [48] worked on a proposal for 
a logic-based language that attempted to balance flexibility and expressiveness 
on the one side, and easy management and performance on the other. The lan- 
guage allows the representation of different policies and protection requirements, 
while at the same time providing understandable specifications, clear semantics 
(guaranteeing therefore the behavior of the specifications), and bearable data 
complexity. Their proposal for a Flexible Authorization Framework (FAF) iden- 
tifies a polynomial time (in fact quadratic time) data complexity fragment of 
default logic; thus resulting effectively implementable. The language identifies 
the following predicates for the specification of authorizations. (Below s, o, and a 
denote a subject, object, and action term, respectively, where a term is either a 
constant value in the corresponding domain or a variable ranging over it). 

cando(o,s, (sign)a) represents authorizations explicitly inserted by the security 
administrator. They represent the accesses that the administrator wishes to 
allow or deny (depending on the sign associated with the action). 
dercando(o,s,(sign)a) represents authorizations derived by the system us- 
ing logical rules of inference (modus ponens plus rules for stratified nega- 
tion). Logical rules can express hierarchy-based authorization derivation 
(e.g., propagation of authorizations from groups to their members) as well 
as different implication relationships that may need to be represented. 
do(o,s,(sigrn)a) definitely represents the accesses that must be granted or de- 
nied. Intuitively, do enforces the conflict resolution and access decision poli- 
cies, that is, it decides whether to grant or deny the access possibly solving 
existing conflicts and enforcing default decisions (in the case where no au- 
thorization has been specified for an access). 
done(o,s,r,a,t) keeps the history of the accesses executed. A fact of the form 
done(o,s,r,a,t) indicates that s operating in role r executed action a on 
object o at time t. 

error signals errors in the specification or use of authorizations; it can be used 
to enforce static and dynamic constraints on the specifications. 

In addition, the language considers predicates, called hie-predicates, for the 
evaluation of hierarchical relationships between the elements of the data system 
(e.g., user’s membership in groups, inclusion relationships between objects). The 
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language also allows the inclusion of additional application-specific predicates, 
called rel- predicates. These predicates can capture the possible different rela- 
tionships, existing between the elements of the data system, that may need to be 
taken into account by the access control system. Examples of these predicates 
can be owner (user, object), which models ownership of objects by users, or 
supervisor (user l,user2), which models responsibilities and controls between 
users according to the organizational structure. 

Authorization specifications are stated as logic rules defined on the predicates 
of the language. To ensure clean semantics and implementability, the format of 
the rules is restricted to guarantee (local) stratification of the resulting program 
(see Figure 22).^*^ The stratification also reflects the different semantics given 
to the predicates: cando will be used to specify basic authorizations, dercando 
to enforce implication relationships and produce derived authorizations, and do 
to take the final access decision. Stratification ensures that the logic program 
corresponding to the rules has a unique stable model, which coincides with the 
well founded semantics. Also, this model can be effectively computed in polyno- 
mial time. The authors also present a materialization technique for producing 
and storing the model corresponding to a set of logical rules. Materialization has 
been usually coupled with logic-based authorization languages. Indeed, given a 
logic program whose rules correspond to an authorization specification in the 
given language, one can assess a request to execute a particular action on an 
object by checking if it is true in the unique stable model of the logic program. 
If so, the request is authorized, otherwise it is denied. However, when imple- 
menting an algorithm to support this kind of evaluation, one needs to consider 
the following facts: 

— the request should be either authorized or denied very fast, and 

— changes to the specifications are far less frequent than access requests. 

Indeed, since access requests happen all the time, the security architec- 
ture should optimize the processing of these requests. Therefore, Jajodia et 
al. [48] propose implementing their FAF with a materialized view architecture, 
which maintains the model corresponding to the authorization specifications. 
The model is computed on the initial specifications and updated with incremen- 
tal maintenance strategies. 

8.2 Composition of Access Control Policies 

In many real world situations, access control needs to combine restrictions inde- 
pendently stated that should be enforced as one, while retaining their indepen- 
dence and administrative autonomy. For instance, the global policy of a large 
organization can be the combination of the policies of its different departments 
and divisions as well as of externally imposed constraints (e.g., privacy reg- 
ulations); each of these policies should be taken into account while remaining 
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A program is locally stratified if there is no recursion among predicates going through 
negation. 
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Fig. 22. Rule composition and stratification of the proposal in [48] 



independent and autonomously managed. Another example is represented by the 
emerging dynamic coalition scenarios where different parties, coming together 
for a common goal for a limited time, need to merge their security requirements 
in a controlled way while retaining their autonomy. Since existing frameworks 
assume a single monolithic specification of the entire access control policy, the 
situations above would require translating and merging the different component 
policies into a single “program” in the adopted access control language. While 
existing languages are flexible enough to obtain the desired combined behavior, 
this method has several drawbacks. First, the translation process is far from 
being trivial; it must be done very carefully to avoid undesirable side effects due 
to interference between the component policies. Interference may result in the 
combined specifications not reflecting correctly the intended restrictions. Second, 
after translation it is not possible anymore to operate on the individual compo- 
nents and maintain them autonomously. Third, existing approaches cannot take 
into account incomplete policies, where some components are not (completely) 
known a priori (e.g., when somebody else is to provide that component). Start- 
ing from these observations, Bonatti et al. [20] make the point for the need of 
a policy composition framework by which different component policies can be 
integrated while retaining their independence. They propose an algebra for com- 
bining security policies. Compound policies are formulated as expressions of the 
algebra, constructed by using the following operators. 

Addition merges two policies by returning their union. For instance, in an 
organization composed of different divisions, access to the main gate can 
be authorized by any of the administrator of the divisions (each of them 
knows which users need access to reach their division). The totality of the 
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accesses through the main gate to be authorized should then be the union 
of the statements of each division. Intuitively, additions can be applied in 
any situation where accesses can be authorized if allowed by any of the 
component policies. 

Conjunction merges two policies by returning their intersection. For instance, 
consider an organization in which divisions share certain documents (e.g., 
clinical folders of patients). An access to a document may be allowed only 
if all the authorities that have a say on the document agree on it. That is, 
if the corresponding authorization triple belongs to the intersection of their 
policies. 

Subtraction restricts a policy by eliminating all the accesses in a second policy. 
Intuitively, subtraction specifies exceptions to statements made by a policy, 
and encompasses the functionality of negative authorizations in existing ap- 
proaches. 

Closure closes a policy under a set of derivation (i.e., implication) rules, w.r.t. 
which the algebra is parametric. Rules can be, for example, expressed with 
a logic-based language (e.g., [48]). 

Scoping restriction restricts the application of a policy to a given set of sub- 
jects, objects, and actions that satisfy certain properties (i.e., belong to a 
given class). It is useful to enforce authority confinement (e.g., authoriza- 
tions specified in a given component can be referred only to specific subjects 
and objects). 

Overriding replaces portion of a policy with another. For instance, a laboratory 
policy may impose authorizations granted by the lab tutors to be overridden 
by the department policy (which can either confirm the authorization or not) 
for students appearing in a blacklist for infraction to rules. 

Template defines a partially specified (i.e., parametric) policy that can be com- 
pleted by supplying the parameters. Templates are useful for representing 
policies where some components are to be specified at a later stage. For in- 
stance, the components might be the result of further policy refinement, or 
might be specified by a different authority. 

Enforcement of compound policies is based on a translation from policy ex- 
pressions into logic programs, which provide executable specifications compati- 
ble with different evaluation strategies (e.g., run time, materialized view, partial 
evaluation) . The logic program simply provides an enforcement mechanism and 
is transparent to the users, who can therefore enjoy the simplicity of algebra 
expressions. The modularity of the algebra, where each policy can be seen as 
a different component, provides a convenient way for reasoning about policies at 
different levels of abstractions. Also, it allows for the support of heterogeneous 
policies and policies that are unknown a priori and can only be queried at access 
control time. 

8.3 Certificate-Based Access Control 

Today’s Globally Internetworked Infrastructure connects remote parties through 
the use of large scale networks, such as the World Wide Web. Execution of ac- 
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tivities at various levels is based on the use of remote resources and services, 
and on the interaction between different, remotely located, parties that may 
know little about each other. In such a scenario, traditional assumptions for 
establishing and enforcing access control regulations do not hold anymore. For 
instance, a server may receive requests not just from the local community of 
users, but also from remote, previously unknown users. The server may not be 
able to authenticate these users or to specify authorizations for them (with re- 
spect to their identity). The traditional separation between authentication and 
access control cannot be applied in this context, and alternative access control 
solutions should be devised. A possible solution to this problem is represented 
by the use of digital certificates (or credentials), representing statements cer- 
tified by given entities (e.g., certification authorities), which can be used to 
establish properties of their holder (such as identity, accreditation, or autho- 
rizations) [39]. Trust-management systems (e.g., PolicyMaker [18], Keynote [17], 
REFEREE [24], and DL [57]) use credentials to describe specific delegation of 
trusts among keys and to bind public keys to authorizations. They therefore de- 
part from the traditional separation between authentication and authorizations 
by granting authorizations directly to keys (bypassing identities). Trust man- 
agement systems provide an interesting framework for reasoning about trust 
between unknown parties; however, assigning authorizations to keys, may result 
limiting and make authorization specifications difficult to manage. A promising 
direction exploiting digital certificates to regulate access control is represented by 
new authorization models making the access decision of whether or not a party 
may execute an access dependent on properties that the party may have, and 
can prove by presenting one or more certificates (authorization certificates in [18] 
being a specific kind of them). Besides a more complex authorization language 
and model, there is however a further complication arising in this new scenario, 
due to the fact that the access control paradigm is changing. On the one side, the 
server may not have all the information it needs in order to decide whether or 
not an access should be granted (and exploits certificates to take the decision). 
On the other side, however, the requestor may not know which certificates she 
needs to present to a (possibly just encountered) server in order to get access. 
Therefore, the server itself should, upon reception of the request, return the 
user with the information of what she should do (if possible) to get access. In 
other words the system cannot simply return a “yes/no” access decision any- 
more. Rather, it should return the information of the requisites that it requires 
be satisfied for the access to be allowed. The certificates mentioned above are 
one type of access requisites. In addition, other uncertified declarations (i.e., not 
signed by any authority) may be required. For instance, we may be requested 
our credit card number to perform an electronic purchase; we may be requested 
to fill in a profile when using public or semipublic services (e.g., browsing for 
flight schedules) . The access control decision is therefore a more complex process 
and completing a service may require communicating information not related to 
the access itself, but related to additional restrictions on its execution, possibly 
introducing a form of negotiation [21,72,89]. Such information communication 
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Fig. 23. Client/server interplay in [21] 



makes the picture even more complex, since it introduces two new protection 
requirements (in addition to the obvious need of protecting resources managed 
by the server from unauthorized or improper access) : 

Client portfolio protection: the client (requestor) may not be always will- 
ing to release information and digital certificates to other parties [65], and 
may therefore impose restrictions on their communication. For this purpose, 
a client may — like a server — require the counterpart to fulfill some require- 
ments. For instance, a client may be willing to release a AAA membership 
number only to servers supplying a credential stating that the travel agent 
is approved by AAA. 

Server’s state protection: the server, when communicating requisites for ac- 
cess to a client, wants to be sure that possible sensitive information about 
its access control policy is not disclosed. For instance, a server may require 
a digitally signed guarantee to specific customers (who appear blacklisted 
for bad credit in some database it has access to); the server should simply 
ask this signed document, it should not tell the customer that she appears 
blacklisted. 

The first proposals investigating the application of credential-based access 
control regulating access to a server, were made by Winslett et al. [82,89]. Ac- 
cess control rules are expressed in a logic language and rules applicable to an 
access can be communicated by the server to clients. The work was also extended 
in [88,93] investigating trust negotiation issues and strategies that a party can 
apply to select credentials to submit to the opponent party in a negotiation. In 
particular, [88] distinguishes between eager and parsimonious credential release 
strategies. Parties applying the first strategy turn over all their credentials if 
the release policy for them is satisfied, without waiting for the credentials to be 
requested. Parsimonious parties only release credentials upon explicit request by 
the server (avoiding unnecessary releases). Yu et al. [93] present a prudent nego- 
tiation strategy to the goal of establishing trust among parties, while avoiding 
disclosure of irrelevant credentials. 
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A credential-based access control is also presented by Bonatti and Samarati 
in [21]. They propose a uniform framework for regulating service access and in- 
formation disclosure in an open, distributed network system like the Web. Like in 
previous proposals, access regulations are specified as logical rules, where some 
predicates are explicitly identified. Besides credentials, the proposal also allows 
to reason about declarations (i.e., unsigned statements) and user-profiles that the 
server can maintain and exploit for taking the access decision. Communication 
of requisites to be satisfied by the requestor is based on a filtering and renaming 
process applied on the server’s policy, which exploits partial evaluation tech- 
niques in logic programs. The filtering process allows the server to communicate 
to the client the requisites for an access, without disclosing possible sensitive in- 
formation on which the access decision is taken. The proposal allows also clients 
to control the release of their credentials, possibly making counter-requests to the 
server, and releasing certain credentials only if their counter-requests are satis- 
fied (see Figure 23). Client-server interplay is limited to two interactions to allow 
clients to apply a parsimonious strategy (i.e., minimizing the set of information 
and credentials released) when deciding which set credentials/declarations re- 
lease among possible alternative choices they may have. 

While all these approaches assume access control rules to be expressed in 
logic form, often the people specifying the security policies are unfamiliar with 
logic based languages. An interesting aspect to be investigated concerns the 
definition of a language for expressing and exchanging policies based on a high 
level formulation that, while powerful, can be easily interchangeable and both 
human and machine readable. Insights in this respect can be taken from recent 
proposals expressing access control policies as XML documents [26,27]. 

All the proposals above open new interesting directions in the access control 
area. 
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Abstract. This material was presented in a series of lectures at fosad, 
a summer school on Foundations of Security Analysis and Design, at the 
University of Bologna Center at Bertinoro in September 2000. It has two 
main purposes. 

The first purpose is to explain how to model and analyze two impor- 
tant security problems, and how to derive systematic solutions to them. 
One problem area is the “packet protection problem,” concerning how 
to use the security services provided by routers — services such as packet 
filtering and the IP security protocols — to achieve useful protection in 
complex networks. The other problem area, the “Dolev-Yao” problem, 
concerns how to determine, given a cryptographic protocol, what au- 
thentication and confidentiality properties it achieves, assuming that the 
cryptographic primitives it uses are ideal. 

Our secondary purpose is to argue in favor of an overall approach to 
modeling and then solving information security problems. We argue in 
favor of discovering security goals for specific domains by examining the 
threats and enforcement mechanisms available in those domains. Math- 
ematical modeling allows us to develop algorithms and proof methods to 
ensure that the mechanisms achieve particular security goals. This leads 
to a systematic approach to trust management, often a more pressing 
information security problem than inventing new and improved security 
mechanisms. 



1 Introduction 

We summarize here a series of lectures at FOSAD, a summer school on Founda- 
tions of Security Analysis and Design, at the University of Bologna Center at 
Bertinoro, in September 2000. 

1.1 The Purpose of These Lectures 

This series of lectures has two main goals. The first goal is to explain how to 
model and analyze two important security problems, and how to design reliable 
solutions to them, namely: 

* Work reported here was supported by the National Security Agency through US 
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1. How to use the security services provided by routers — services such as packet 
filtering and the ip security protocols — to achieve useful protection in com- 
plex networks; and 

2. How to determine, given a cryptographic protocol, what authentication and 
confidentiality properties it achieves, assuming that the cryptographic prim- 
itives it uses are ideal. 

We refer to these two problems as the packet protection problem and the Dolev- 
Yao [9] problem respectively. 

The second goal is to argue in favor of an overall approach to modeling and 
solving information security problems, based around three ideas: 

1. There does not exist any single property, which if we achieve it, will provide 
the information security we need in every situation. 

Instead, in each application area we must analyze the kinds of threat we face. 
From this, we can abstract a class of properties that capture the different 
meaningful protections in this type of situation. We call each property in the 
class a “security goal,” and we regard the class itself as defining the range 
of security that may need to be provided in this application area. 

Different application areas will lead to different classes of security goals, 
formulated in terms of different modeling ideas. 

2. Security goals need to be expressed using a simple, well-understood vocabu- 
lary of mathematical notions, and we will use the same vocabulary to model 
systems, the systems that we want to ensure will meet these security goals. 
In this series of lectures, the mathematical vocabulary we use will include 
boolean algebras and freely generated algebras of terms, as well as graphs. 
The graphs will include directed and undirected graphs, and at various stages 
we will need to partition either the nodes or the edges into distinct classes. 
Needless to say, this vocabulary is very familiar and very easy to reason 
about. 

3. These mathematical notions themselves suggest algorithms and proof meth- 
ods that are useful for security management. The mathematical notions lead 
to flexible and efficient ways to resolve problems, such as: 

(a) Does a given system meet a particular security goal? 

(b) Given a system, what security goals does it meet? 

(c) Given a security goal, how can we configure (or modify) a system to 
meet it? 

(d) Given a real-world system, how can we construct the abstraction that 
models it? 

(e) Given a real-world system, what automated tests (or manual analysis) 
will check whether a given abstraction models it faithfully? Whether 
a given security goal has been violated? 

(f) If two given systems each meet a security goal, does each continue to 
meet that security goal if they are combined in a particular way? 

These questions are the core of the crucial real-world problem of security 
management. 
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1.2 The Structure of These Lectures 

We divide the remainder of our report into five sections. 

Section 2 Packet Trajectories: Derived from [11,13]. Coauthors: A. Herzog and 
J. Thayer. 

Contents: Introduce the packet protection problem. Define a class of secu- 
rity goals that filtering routers can achieve. Network model. Algorithms to 
determine whether given filtering behavior achieves a goal, and to assign 
filtering behavior that will achieve a given goal. Abstraction from router 
configuration files. 

Section 3 Strand Spaces and Protocol Security Goals: Material derived from 
[47]. Coauthors: J. Herzog and J. Thayer. Also from [14,16]. Coauthor: 
J. Thayer. 

Contents: Cryptographic protocols and the Dolev-Yao problem. Why crypto- 
graphic protocols fail: Unintended services. Powers of the penetrator. Strand 
space definitions. Authentication and secrecy goals. 

Section 4 Well-Behaved Bundles and Paths through Them: Material derived 
from [16]. Coauthor: J. Thayer. 

Contents: Bundle equivalence. Redundancies and redundancy elimination. 
Paths. The normal form lemma. Rising and falling paths, bridges, efficiency. 
Proof of the secrecy theorem. 

Section 5 Authentication Tests: Material derived from [14,16]. Coauthor: 
J. Thayer. 

Authentication tests: proving authentication and secrecy. Proofs of the au- 
thentication test results. Application to examples. 

Section 6 Protocol Independence via Disjoint Encryption: Material derived 
from [15]. Coauthor: J. Thayer. 

Contents: Multiprotocol strand spaces, independence. Disjoint encryption. 
Applications of protocol independence. 

Copies of the papers cited above are available at URL 

http : / / WWW . CCS . neu . edu/home/guttmeui/. 
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2 The Packet Protection Problem 

In this section, we explore one security mechanism, namely filtering routers (and 
firewalls of related kinds). They are widely used to protect enterprises or their 
parts from attacks that could be launched from outside them. Wide practical 
experience exists as to the types of packets (identified by the ip, TCP and UDP 
headers) that are most capable of causing harm to their recipients, and firewall 
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administrators configure their enforcement mechanisms to trade the danger of 
incoming datagrams off against the value of the network services that they pro- 
vide and the level of trust in those that may have crafted the datagrams. We 
will describe a systematic method to ensure that security policies of this kind 
are faithfully implemented, despite the topological complexity of the networks. 
Most of this material is contained in [11] in a more systematic style, although 
the material on abstraction is previously unpublished. 

We have carried out a similar study of how to use the ip security protocols 
(IPSEC) to achieve genuine confidentiality, authentication, and integrity. The ip 
security protocols apply cryptographic operations to individual datagrams, and 
they may be active either at the end systems (source and destination) exchang- 
ing the datagrams, or else at intermediate routers (“security gateways”) that 
provide cryptographic services on behalf of nearby end systems. Indeed, IPSEC 
is currently used predominantly at security gateways, and there are large po- 
tential advantages of management in doing so. A systematic way to be sure of 
reaping those benefits is needed. That material is instead available in [13]. 

We start by considering the security goals that we would like to achieve. From 
those, we infer a way of modeling the goals (and the systems that should meet 
those goals) using simple mathematical notions. They in turn suggest algorithms 
to solve our security management problems. 

2.1 Packet Filtering 

The purpose of packet filtering is to prevent the delivery of packets that may 
harm the recipient, or occasionally to prevent the transmission of packets con- 
sidered inappropriate (e.g. http requests to unwholesome servers). The filtering 
point must typically decide what action to take without examining the payload; 
only the headers are typically examined by the devices we are concerned with. 
Thus, aspects of the headers must be used as a clue to which packets ought to 
be discarded. 

2.2 An Example 

For instance, icmp destination unreachable packets may be used to map an or- 
ganization’s network, to the extent of determining what ip addresses are in use 
and which routers are nearby. The attacker sends unsolicited ICMP destination 
unreachable messages with source ip address s into the organization. If the desti- 
nation address d for that message is not in use, then a router r near the network 
on which d would lie sends back an outbound icmp destination unreachable 
packet, with destination s. The source address for this packet is an ip address 
r for the router itself. In this way, the attacker learns which addresses are not 
in use (because an icmp packet is returned); the rest are in use. He also learns 
which router r serves each missing ip address. 

The scheme works because most firewalls permit icmp destination unreach- 
able packets to pass, because they are a useful part of the network infrastructure. 
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If an organization would like to prevent this sort of probing, then its admin- 
istrators need to configure their routers (or firewall) to prevent it. They would 
prefer to allow as many ICMP packets as possible to pass around the network, 
so long as the attack is prevented. To prevent the attack with the least loss 
of service, the administrators would like to select a small number of filtering 
routers. Those routers will be the enforcement points. Each path should traverse 
an enforcement point, if that path leads from a network area where the attack 
might be launched to a network area whose contents should not be disclosed. 

The enforcement point could discard inbound icmp probes; indeed, it would 
suffice to discard inbound probes with destination addresses d that are not in 
use. The outbound replies are generated only for these addresses, so filtering 
these probes will ensure that no information is returned. Of course, this finer 
strategy can be used only if this set is known when the router configuration 
is chosen. Alternatively, the router could discard the outbound ICMP response, 
although in this case the packet source address is r, so that we cannot fine-time 
the behavior depending on which addresses are in use. 

2.3 Types of Information in Our Security Goals 

There were two phases to the reasoning we have just described. One was to deter- 
mine a potential kind of attack, and to infer from it a kind of packet that should 
be discarded, depending where that packet had come from. In the second phase, 
we looked for enforcement points, and attempted to assign filtering behavior to 
each enforcement point with the consequence that every harmful packet’s path 
would be disrupted. We try to do so without disrupting the paths of too many 
other packets. 

The security goal here is to prevent the delivery of certain packets, and the 
definition of which packets involves two different types of information. First, it 
concerns what the header of the packet says. In our example, we were concerned 
with the following ip header fields or protocol-specific header fields: 

— The protocol header field in the ip header, which must indicate ICMP for this 
concern to be relevant; 

— The ICMP-specific fields for message type and message code, which jointly 
indicate a destination unreachable message; 

— The IP destination address, in case we wish to filter only inbound probes 
destined for addresses not in use. 

In other examples, we would be concerned with the ip source address, or other 
protocols such as TCP or udp, or with the protocol-specific fields for those proto- 
cols, such as source or destination port number, and the TCP syn and ack bits. 
All this information is contained in the datagrams, and available to any router 
inspecting it. 

The other kind of information concerns the path that the packet has taken 
through the network. If the packet has never been on the public Internet, then 
we do not have to worry whether it is an attempt to map our networks. That is. 
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assuming that we trust our employees not to attack us, or we acknowledge that 
they have other ways to obtain mapping information if they intend to carry out 
an attack. 

The path information is not contained in the packet itself (certainly not in any 
reliable form, given the ways that packets can be spoofed). Indeed, no individual 
router can observe the whole path, but different routers observe different small 
pieces of the path. The behavior of a router for a packet it receives is sensitive 
to which interface the router received it over; and the behavior of a router for 
a packet to be transmitted is sensitive to which interface it will be transmitted 
over. The access lists governing filtering are specified on an interface-by-interface 
basis. Thus, they are sensitive to a portion of the path. The art of achieving 
the desired network-wide security therefore requires us to do different filtering 
at different points in the network, thereby disrupting the paths that worry us. 
A typical example network, containing enough information to represent the paths 
of concern to us, may take the form shown in Figure 1. 




The task of deciding on a security policy is simplified by the fact that infor- 
mation we care about is a limited portion of the path information: We care only 
whether the datagram was previously in a network region we do not trust, and 
whether the datagram has reached a region we would like to protect. A firewall 
policy can also enforce a confidentiality policy, thereby restricting the flow of 
packets from a vulnerable (internal) area to an untrusted (external) area. The 
strategy of filtering the outbound return ICMP packets in our example is a case 
of enforcing confidentiality (with regard to network information) via a firewall. 
Naturally, more inclusive kinds of confidentiality are likely to be harder to en- 
force reliably using a firewall. 
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2.4 The Logical Form of Our Security Goals 

From our intuitive analysis, we can now stipulate the logical form of the secu- 
rity goals we would like to achieve. They integrate information about path with 
information about header in a specific way. A security goal always concerns two 
network areas a and a' , with one (say, a) traversed earlier and the other a' tra- 
versed later. If a packet has followed any path from a to o', then its header fields 
should have some property (p. Thus, a “policy statement” for pair of areas a, a' 
is a statement of the form: 

If p was in a and later reaches a', 

then p’s header fields satisfy p. 

Thus, for our firewall analysis, we have identified a class of security goals. Each 
goal describes a class of paths — those that traverse the areas a and a' in that 
order — and says which packets, defined in terms of header fields, are permitted 
to travel along those paths in the network. These firewall security goals are 
characterized by this logical form, namely an implication in which the antecedent 
mentions two areas in a particular order, and the consequent gives a constraint 
on the packets traversing those areas. 

A security policy, in this context, will mean a security goal for every pair of 
areas. Given a graph in which the areas belong to a set A, a policy is a function 
II: A X A ^ B, where B is some suitable collection of sets of packets. 

In other contexts, other security goals will be needed. For instance, the se- 
curity goals we can achieve using IPSEC, as have discussed in [13], may take 
different logical forms or require different real world ingredients to be modeled. 

2.5 Some Security Goals 

We have already mentioned two candidate security goals, each a possible way to 
prevent the ICMP destination unreachable network mapping attack. First, we may 
prevent the attack by pruning the incoming probe. We assume that the attack 
is possible only if the probe packet has passed through the External area (in 
the terminology of Figure 1), and we assume that we are concerned only about 
an attacker mapping our internal networks, labelled Engineering and Financial. 
The Periphery network, being more exposed, may well be vulnerable to mapping 
in any case. Thus, one security goal would be: 

If p was in External and later reaches Engineering, 

then p’s header fields satisfy p, 

where p stipulates 

Either p. destination ^ Engineering, 
or p. protocol ^ icmp, 

or p. message-type ^ destination unreachable. 
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Another example security goal in this network (assuming that most TCP con- 
nections are proxied at the application level on the Proxy host on the Periphery 
network) may be to ensure that no TCP packet travels from External to Engineer- 
ing unless it is an SMTP packet, and its destination is the email server Engjuail. 
In this case, the antecedent of the policy statement is unchanged, since we are 
still concerned with what packets reach Engineering from External; the choice 
of If is then: 

p. destination = Eng_mail, 
and p. protocol = TCP, 
and p.destjport = 25. 

2.6 Security Modeling 

Our analysis of the security goals we would like to achieve also suggests some 
modeling decisions. We must model the paths of packets as they pass from a net- 
work area across an interface to a router and then across another interface to 
some other network area. Thus, we may regard the system as forming a graph. 
The edges represent the interfaces, and since packets may flow in either direc- 
tion over an interface we may regard the edges as undirected. The nodes are of 
two different kinds, namely the router at one end of an edge and the network 
area at the other end. Thus, we represent the system by a bipartite graph with 
undirected edges. A diagram like Figure 1 summarizes this view of the topology 
of the system. 

Now, at each edge, for each direction, we have a filter that will be used to 
discard some packets that would otherwise flow in that direction. The Alter di- 
vides all packets into two sets, those that are permitted to flow over the interface 
in that direction and those that will be discarded. Since different characteris- 
tics of packet headers will be used to make these decisions, but presumably not 
every set of packets will be relevant, we will regard the relevant sets of packets 
as forming a boolean algebra, always a vastly smaller boolean algebra than the 
boolean algebra of all sets of packet headers. 

Since there are thirty-two bits of source address, thirty-two bits of destination 
address, and eight bits for selecting protocols, there are at least 2^^ different ip 
headers, so at least 2^ different sets of ip headers. For ICMP there are sixteen 
bits of protocol specific message type and message code; for TCP there are sixteen 
bits of source port and sixteen bits of destination ports, and likewise for udp. 
Thus, we have many more sets considering these protocol specific header fields. 
Naturally, many of these sets are ridiculously ragged, and play no role in any 
meaningful network protection. The “practically useful” sets are comparatively 
few and far between, and have smoother edges. 

In our example above, there are just a few distinctions we need among ip 
addresses. The special hosts have ip addresses that must be distinguished from 
all others, since Alters will need to permit packets through specially, if those 
hosts are source or destination. Then the workstations in a particular network 
area may need to be distinguished from those in any other area. Finally, for our 
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ICMP example, we might want to distinguish the unused ip addresses in the three 
internal corporate networks. This leads to a total of twelve relevantly different 
IP addresses, far less than the 2^^ different addresses a priori. There is a big 
advantage to taking a special-purpose representation of the boolean algebra of 
relevant packet sets, rather than using a representation that could express all 
the addresses and all the sets of addresses, and all the sets of packet headers. 

Thus, our modeling process leads us to two ideas, the idea of a undirected 
bipartite graph to represent the network, and the idea of a boolean algebra to 
represent the constraints, both the sets permitted at the various filtering points 
and also the :/5S used in the consequents of security goals. Let us see now what 
problems we can solve using these two modeling ideas. 

2.7 Localization 

The core issue with our packet filtering security policies concerns localization. Al- 
though our security properties are global properties about all paths from a to o', 
even when these areas are distant from each other, our enforcement mechanism 
consists of routers each of which must make its own decision. It has only local 
information about what interface a packet has been received over, and what 
interface it will be transmitted over. Localization is the problem of achieving 
global security goals using this local information. 

Localization may be used in two different ways. First, we may know what 
security goals we want to achieve, and also the filtering that will be applied 
on each interface to packets flowing in each direction. Then the problem is to 
decide whether each security goal is enforced by those filters. When they are 
not satisfied, one would like to exhibit the undesirable packets and the paths by 
which they may reach their targets. 

Alternatively, we may decide on the security goals, and wish to discover an 
assignment of filtering to interfaces that will achieve them. Each of these two 
problems is a matter of localization, because the problem is to interrelate security 
policies stated in terms of network-wide paths, with an enforcement mechanism 
that must act locally at specific interfaces. 

We will use the word posture to mean a specification of filtering behavior. 
Filtering routers allow a different set of packets to be filtered at each interface, 
and in each direction of flow, into the router or out of the router. Thus, a filtering 
posture will mean an assignment of a filter to each interface/direction pair. 
A filter just means a set of packets, namely those permitted to traverse the 
interface in that direction. The sets of packets are the members of some boolean 
algebra that will be far smaller than the boolean algebra of all sets of packet 
headers. 



2.8 Two Algorithms 

We have mentioned two problems, namely 
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1. Given a security policy and a filtering posture, to determine whether the 
posture faithfully enforces the policy, and if not, to enumerate the coun- 
terexamples; and 

2. Given a security policy, to construct a filtering posture guaranteed to enforce 
the policy. 

We will describe an algorithm to resolve each problem, for which we need some 
auxiliary notions. Let p = (£o, ■ • ■ ,^n) be a path p. Here, each £i is either an 
area or a router in a bipartite graph such as the one in Figure 1, and p is a path 
only if ii and £i+i are adjacent for each i from 0 to n — 1. We will write pi for 
the i**' entry in p; we will write \p\ for the length of p; and we will write p|p| 
for the last entry in p. We use p^p' to mean the concatenation of p with p', 
which is well-defined only if p|p| = pg, and is the path consisting of p followed 
by p^, omitting the second occurrence of the common location at the end of p and 
beginning of p' . 

We also assume to simplify notation that each router has at most one interface 
on any area. Thus, we regard a filtering posture as a function f : Rx Ax D ^ B, 
where 

R is the set of routers; 

A is the set of areas; 

D is the set containing the two directions in and out, meaning into the router 
and out of the router, respectively; and 
H is a boolean algebra of sets of packets. 

We adopt the convention that /(r, a, d) = 0 when r lacks an interface on a. 
Let 4‘{£i,£j) = f{£i,£j, out) when £i is a router and £j is a network area, and 
f{£j,£i,in) otherwise. Thus, in either case it is the set of packets allowed to 
traverse the interface from £i to £j. 

We define £F{p), the feasibility set for p, inductively: 

1. £F{{)) = £F{{£o)) = T, the top member of the boolean algebra; 

2. .F(p-'(4,4+i)) = R{p) n </.(4,£,+i). 

Thus, the feasibility set for a path p is the set of packets that survive all of the 
filters that are traversed while following p. Observe that if the range of a filtering 
posture / is in the boolean algebra B, then £F{p) is also in B, for any p. Also, 
by the laws of boolean algebra, £F{p^p') = T{p) n £F{p’). 

2.9 Posture Checking 

Suppose given a posture / and a security policy U: A x A ^ B, we would like 
to know whether / enforces U. What does this mean? 

It means that whatever path a packet may take from area oq to a„, if that 
packet survives every filter it traverses, then it satisfies the policy constraint 
d^(p) C 7T(po,p|p|). 
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Note also that we may ignore any cyclic path p = (£q, ■ • ■ , ■ ■ ■ , ■ -^n) , 

because 

T{p) = ^((4, . . . , £,)) n , £,)) n , O) 

So p cannot cause more violations than its cycle-free part {Iq, ^n)- 

Therefore, to find all violations, we need only enumerate, starting at each 
area a, each cycle-free path p leading to another area a' = p\p\. We test T{j>) C 
n{a,a'). If this is false, we report as violations all packets in the set-difference 
J-{p) \ n{a,a'), noting that the path p permits them to pass. If no cycle-free 
path starting at any area a leads to violations, then / correctly enforces U. 

Doubtless, this algorithm could be made more efficient in several ways were 
it necessary to handle large graphs. 

2.10 Posture Generation 

Suppose next that we have a security policy U that we want to enforce, and the 
task is to construct a filtering posture / that does so. The idea of this algorithm 
is this: We start with a simple but useful initial posture /o, and we correct it 
successively to eliminate all violations. 

The correction process enumerates all cycle-free paths p that start and end 
at distinct areas ag and a„. The next-to-last entry in p is a router r, because 
the underlying graph is bipartite. Using the current approximation fi, we cal- 
culate J^(p). If -^(p) C 7T(ao,a„), then /i+i = fi. Otherwise, we correct the 
violations U, which are the packets in the set difference V = lF(p) \ 77(ao, a„), 
those packets that may feasibly traverse the path p but are not permissible. The 
corrected posture /i+i differs from fi only for the arguments {r,an, out), where 
we have /i+i(r, a„, out) = fi{r, a„, out)\V. Observe that this algorithm modifies 
only the outbound filters, not the inbound ones. 

There are different strategies for constructing the initial posture fg. A useful 
choice is the following. 

1. fg{r,Qn, out) = T, the top member of the boolean algebra; 

2. For any datagram S, S € fg(r, a, in) if S.src G a, or else if, every a' adjacent 
to r, S.src ^ a'. 

This choice of fg uses the inbound filters to protect against spoofing: If a data- 
gram S claims a source in some adjacent area a' , but is observed entering r from 
some different adjacent area a, then 5 must be lying. If it were really from a' , 
it would reach r off its interface on area a' . This reasoning assumes that the 
packet has not been routed along on odd path because some network resources 
are currently down, but it matches an assumption that security-attuned network 
administrators frequently want to make. 
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This algorithm is not guaranteed to be ideal. The correction process discards 
packets only at the last step, immediately before they would finally cause a vi- 
olation. It may be preferable instead, in a particular case, to discard the packet 
earlier, as it embarks on a path that will eventually lead to violations. Similarly, 
the choice of an anti-spoofing initial posture /q may not be ideal. For instance, 
a packet arriving at the External/Periphery router in Figure 1, inbound on its 
External interface, which claims to be from Finance, is doubtless lying, but our 
initial posture /o does not discard it. The reason is that Finance is not adja- 
cent to this router. We know something about the way that packets from Finance 
should travel, but it would be hard to generalize that knowledge and incorporate 
it into our algorithm. 

A reasonable implementation, such as the one described in [11] or its succes- 
sor, the current Network Policy Tool (npt) software available from the author, 
will combine this posture generation algorithm with the posture checking algo- 
rithm described previously. Then a human user can edit the posture output by 
the generation algorithm to make local improvements. The checking algorithm 
may then be used to ensure that these “improvements” have not in fact in- 
troduced violations. Alternatively, to understand why npt has done something 
apparently unnecessarily complex, it is interesting to edit the output to the sim- 
pler, expected form. The checking algorithm will then show what would have 
gone wrong. 

If one is given a posture /, it is also possible to calculate a security policy 
that describes what / permits; it is the policy Uf inferred from /. It is defined 
by: 

nj{a,a') = IJjP(p) 

p 

where the union is taken over all p of the form p = (a, . . . , o'). 

2.11 Implementing Boolean Algebras 

Any such piece of software needs to select a suitable data structure to represent 
the members of the boolean algebra. Different possibilities may be tried, although 
it is natural to regard each packet as a triple, consisting of a source ip address, 
a destination ip address, and “the rest.” 

The rest consists of information about the network service that the packet 
provides. It includes the packet’s protocol field (possible values being TCP, UDP, 
ICMP, and so on), together with a variety of protocol specific fields. For instance, 
for UDP and TCP, the source port and destination port are important. If the 
destination port is a well-known value like 25, then this packet is headed toward 
a server (in this case an SMTP server); if its source port is 25, then it is headed 
from an SMTP server to a client. 

For TCP, so are the syn and ack bits that say whether the packet belongs 
to the set-up phase of a connection, or to a connection that has already been 
negotiated. For icmp, the message type and code are relevant. 
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Since each packet is characterized by the three dimensions of source, des- 
tination, and service, a boolean algebra of sets of packets may be regarded as 
consisting of regions of a three dimensional space. Although it is a large space, 
we are in fact interested only in rather coarse regions. For instance, looking at 
a diagram such as Figure 1, we can see that the number of relevantly different 
addresses is quite low, nine in fact: 

— There are four specific systems mentioned, that will need special treatment in 
defining policy and implementing a suitable posture. They are engineering 
db, engineering mail, finance mail, and periphery proxy. 

— Hosts other than these are treated uniformly according to the area in 
which they are located. Thus, we have engineering other, finance other, 
periphery other, external any, and allied any. 

We also call these “relevantly different” addresses abstract addresses. 

A similar consideration of the protocols and services that the network sup- 
ports, and of the policy for permitting them from area to area, might lead to 
a short list of relevantly different services, for instance, 

— ICMP, distinguishing destination unreachable messages from all others; 

— TCP, distinguishing ftp, smtp, and http by their well-known ports; 

~ UDP, distinguishing messages to a particular port on the engineering db 
machine, on which a data base server is listening; 

— all other protocols. 

In addition, for the distinguished TCP and UDP services, one will want to treat 
packets differently depending whether the packet is traveling from client to 
server or vice versa; this doubles the number of distinguished TCP and UDP ser- 
vices. There is one additional service grouping together all others, the “undistin- 
guished” services. On our example, we have thirteen relevantly different services: 

— Two ICMP services; 

— Seven (= 3 • 2 -|- 1) TCP services; 

— Three (= 1 • 2 -|- 1) UDP services; 

— One for the others. 

We also call these relevantly different services abstract services. 

All in all, there are 9-9T3 = 1053 relevantly different packets in this example, 
leading to 2^°®^ sets in the boolean algebra. Naturally, far fewer sets will come up 
in any relevant computation. Observe that these “relevantly different packets,” 
called “abstract packets” in [11], are the atoms of the boolean algebra, in the 
sense that any two atoms have a null intersection, and any set in the algebra is 
a union of atoms. Thus, an abstract packet is a triple, consisting of two abstract 
addresses (source and destination) together with an abstract service. Examples 
of these abstract packets, shown as triples of abstract source, destination, and 
service, would be: 

(external any, engineering any, ICMP dest unreachable) 
(engineering db, allied any, UDP db from server) 

(engineering mail , external any, TCP smtp to server) 



210 



Joshua D. Guttman 



Each of these represents a set of possible concrete (real) packets, namely all 
those with ip addresses matching the source and destination, and protocol spe- 
cific header fields matching the service. It thus represents a cube in the three 
dimensional space of real datagrams, being the intersection of the sets of packets 
matching each of the three dimensions individually.^ There are different ways to 
represent the algebra with these atoms. In NPT, we represent any set as a list of 
cubes, although we treat the source and destination dimensions specially. The 
lists are maintained in a form such that no source destination pair lies in the 
projection of two different cubes. For this reason, we described the lists as lists of 
colored rectangles, where the source-destination rectangles were always disjoint, 
and the permissible services for the packets with those sources and destinations 
were regarded as a coloring. 

Wool and his colleagues [34] follow [11] in representing sets of packets as 
lists of disjoint colored rectangles, although in their work the relevantly different 
sources and destinations are not inferred at the start. Instead, they are con- 
structed by examining real configuration files, and splitting ip addresses into 
ranges according to the access list lines contained in the configuration files. 

One might alternatively dispense with lists of rectangles and instead represent 
the sets more directly, for instance using Binary Decision Diagrams (bdds) [3]. In 
our next section, we will instead consider how bdds can be used as an auxiliary 
structure to discover the set of atoms that naturally describe existing configu- 
ration files. 



2.12 The Abstraction Problem 

We have described how to use a boolean algebra in which the atoms are abstract 
packets as a way to represent problems about distributed packet filtering. But, 
how can we construct a boolean algebra that is faithful to the distinctions made 
in a particular set of configuration files? That is, we would like to take the 
configuration files for a given set of filtering routers, and deduce from them 
a set of abstract addresses and abstract services, such that the filtering posture 
determined by these configuration files can be represented in the resulting three 
dimensional boolean algebra. Indeed, we would prefer to choose the coarsest such 
boolean algebra, so that our abstract addresses and services make the minimum 
number of distinctions compatible with the files themselves. This is the problem 
addressed in [12], for which the binary decision diagram is an ideal data structure. 

An abstract address is a set s of concrete ip addresses such that i,j € s implies 
that replacing i by j as the source or destination of a packet never transforms 
a packet rejected by a filter into a packet accepted by it, or vice versa. A set of 
IP addresses is an atom for a filtering posture is this holds for all of the filters 
specified by its configuration files. 

^ If there were some natural sense of adjacency for the points on the axes, this would 
amount to a finite union of cubes. Since we do not recognize any natural notion of 
adjacency, we collect together the matching intervals along any one axis, and regard 
the region as a single cube. 
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The problem is the more pressing because the router configurations of real 
organizations evolve over time as hosts and routers are added to the network or 
removed; as users clamor for additional services or administrators worry about 
new attacks; and as staff comes and goes with an increasingly hazy understanding 
of the contributions of their predecessors. Indeed, their decisions are typically 
documented only in the configuration file itself, with its low-level, procedural 
notation and inflexible syntax. 

From our point of view, a configuration file such as for a Cisco router, con- 
tains interface declarations and access lists. An interface declaration may specify 
a particular access list to apply to packets arriving inbound over the interface 
or being transmitted outbound over the interface. 

An access list is a list of lines. Each line specifies that certain matching pack- 
ets should be accepted (“permitted”) or discarded (“denied”). When a packet 
traverses the interface in the appropriate direction, the router examines each 
line in turn. If the first line that matches is a “deny” line, then the packet is 
discarded. If the first line that matches is a “permit” line, then the packet is per- 
mitted to pass. If no line matches, then the default action (with Cisco routers) 
is to discard the packet. 

For instance, the lines in Figure 2 permit two hosts (at ip addresses 129.83.10.1 
and 11.1) to talk to the network 129.83.114.*. They also permit the other hosts 
on the networks 129.83.10.* and 129.83.11.* to talk to the network 129.83.115.*. 
The asterisks are expressed using a netmask 0.0.0.255, meaning that the last 
octet is a wildcard. 



(comments start with !) 



! keyword 


num 


action 


prot 


source 


destination 




access-list 


101 


permit 


ip 


host 


129.83.10.1 


129.83.114.0 


0.0.0.255 


access-list 
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permit 


ip 


host 


129.83.11.1 


129.83.114.0 


0.0.0.255 


access-list 
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deny ip 


host 


129.83.10.1 


any 




access-list 
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deny ip 


host 


129.83.11.1 


any 




access-list 
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permit 


ip 


129. 


83.10.0 0.0.0.255 


129.83.115.0 


0.0.0.255 


access-list 


101 


permit 


ip 


129. 


83.11.0 0.0.0.255 


129.83.115.0 


0.0.0.255 



Fig. 2. A cisco-style access list 



2.13 The Logic of Access Lists 

Each line of an access list defines a set of sources (ps, destinations pd, and service 
characteristics (py, and stipulates whether matching packets should be discarded 
or passed. A datagram S matches a line if S.src G Ps S.dst G pd S.svc G Pv 
At any stage in processing, a packet that has not yet been accepted or rejected 
is tested against the first remaining line of the list. If the line is a “permit” line. 
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the packet has two chances to be permitted: it may match the specification for 
the first line, or it may be permitted somehow later in the list. If the line is 
a “deny” line, the packet has to meet two tests to be permitted: it must not 
match the specification for the first line, and it must be permitted somehow 
later in the list. Since the default is to deny packets, the empty list corresponds 
to the null set of permissible packets. Thus, we have a recursive function 77 of 
the access list: 

^([]) = 0 

ri{{^eru\\t,ips,^d,^v) r) = {ips ^ ^v) ^ 

r) = r]{r) \ {(ps D (fid (fiv) 

The function 77 allows us to transform a parser for the individual configuration 
file lines (emitting sets describing the matching conditions) into a parser that 
emits a set describing the meaning of the whole access list. 

2.14 Binary Decision Diagrams 

Again we face the question how to implement the boolean algebra of sets in 
this context, and for our current purpose of solving the abstraction problem, the 
binary decision diagram [3] fits our needs perfectly. 

A binary decision diagram (bdd) is a finite directed acyclic graph with two 
sinks, labelled true and false. Each interior node has out-degree two, and is 
labeled with a propositional (bit-valued) variable. One out-arrow is associated 
with the variable taking the value true and the other with the variable taking 
the value false. One node is distinguished as the root. 

A BDD n represents a propositional function; that is, it yields a truth value as 
a function of a number of truth- valued variables: to evaluate it for an assignment 
of values to the variables, we start at the root and follow a path determined as 
follows: 

1. If we have reached a sink, its label is the result. 

2. If the current node is labeled with variable v, and the assignment associates 
7 ; I— > 6 , then we traverse the arrow associated with the value h. 

Observe that any node n' accessible from a bdd n is itself a bdd. If a is an 
assignment of truth values to the variables, then we write ain) for the truth 
value that results from evaluating n at a, i.e. traversing n as described above. 

An example is shown in Figure 3, page 214. Each node represents a choice 
for the truth value of the variable shown at the right margin. The line marked -I- 
represents the result if that variable is true; the other line represents the result 
if that variable is false. 

A BDD n is ordered if there exists an ordering ^ on the variables such that 
7; ^ if any traversal starting at n encounters v before v' . A bdd n is reduced 
if, whenever tiq and ni are accessible from n and tiq 7 ^ ui, then there is some 
variable assignment a such that a(rio) 7^ a{ni). Thus, a bdd is reduced if its 
nodes obey the extensionality principle that different nodes represent different 
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propositional functions. Algorithms for maintaining bdds in ordered, reduced 
form are found in [2]. 

In our case, we are interested in using bdds to represent sets of packets. Since 
a packet is determined by source address, destination address, and protocol- 
specific information, the propositional variables are the thirty-two bits of the 
source address (for ip Version 4), the thirty-two bits of the destination address, 
and a number of bits representing the protocol-specific information (sixty-four 
bits is enough). Thus, any protocol header may be summarized, to the extent we 
need to model how filter routers treat it, as a sequence of 128 bits. Any filter (set 
of packets) may therefore be represented as a reduced, ordered binary decision 
diagram where each internal node is labeled with one of these 128 propositional 
variables. 

An example bdd is shown in Figure 3; in this diagram, we have assumed 
that IP addresses are only three bits, and that protocol-specific information may 
be summarized in four bits. The nodes are thus labeled si,S 2 ,S 3 , di,d 2 ,d, 3 , 
and pi,P 2 ,P 3 ,P 4 - The variables are grouped into three sections representing 
source information, destination information, and protocol information. 

2.15 Finding Atoms in BDDs 

Suppose that we are given a bdd like the one in Figure 3, in which the variables 
have been divided into sections. We would like to identify the sets of values 
in each section that are treated as atoms. For instance, we will identify the 
sets of IP addresses that are treated the same as packet source addresses, so 
that if two addresses i,j belong to the same atom, then a packet with source 
address i and the identical packet with source address j will necessarily receive 
the same treatment from the packet filter. Two concrete addresses belong to 
the same abstract addresses if they are treated the same as sources and also as 
destinations. 

To find the source atoms, we will enumerate the outcomes, meaning those 
nodes that are not labeled by source variables, but lie at the end of an arc 
starting at a node labeled by a source variable. In our example (Figure 3), one 
of these nodes is enclosed in a small box. If two paths lead to the same outcome, 
then those paths can make no difference: in combination with any assignment 
to the remaining variables, either both paths evaluate to true or else both paths 
evaluate to false. For instance, let pi be the path that assigns T to si and S 2 , 
and F to S3; let p 2 be the path that assigns F to si and S2, and T to S3. Then 
both Pi and p 2 lead to the boxed outcome. Therefore they must belong to the 
same source outcome. 

On the other hand, if two paths through the source variables lead to dif- 
ferent outcomes, then because the bdd is in reduced form, there must be at 
least one assignment to the remaining variables that leads to different outcomes. 
Therefore, the paths do not belong to the same source atom. 

This way of thinking suggests some definitions and an algorithm. First, let 
us call a sequence of variable/ value pairs a path if the variables occur in an order 
compatible with Some examples of paths involving only source variables are: 
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Fig. 3. An example bdd 
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(sijtrMe), {s2,true), {33, false) 

(sijalse), (s2,/afee), {33, true) 

{si, false), {33, true) 

We say that a path p leads from ng to rife, and write rig — ^ rife, if there is 
a sequence of arcs leading from rig to rife, and each node for i < k is labeled 
by a variable Vi mentioned in p, and the arc from to rij+i is labeled by the 
truth value paired with Vi in p. There may be several paths leading from rig to rife . 
On the other hand, a particular path may not lead anywhere in a given bdd: 
the third path just mentioned does not lead anywhere in the bdd of Figure 3. 
In that BDD, each path involving si and S3 needs also to specify a value for S2- 
We may interpret each path as a formula in the obvious way, namely as a con- 
junction in which each variable in the path occurs negated if the associated value 
is false and unnegated if it is true. For convenience, we write the interpretation 
of a path p as |p]. With this notation, we have the following interpretations for 
our example paths: 

\{si,true), (s2,true), {33, false)] = si A S2 A ^sg 

l(si, false), {s2, false), {33, true)] = ^si A ^S2 A S3 

|(si,/afee), {s3,true)j = ^si A S3 

If s is a set of paths, we use |s] to mean the disjunction VpgsM- Thus, for 
instance, if s contains the three paths mentioned above, then 

|s] = (si A S2 A ^53) V (^S2 A ^53) V (^Si A S3) 

We also say that ni is an outcome for n if for some path p, n — ^ m, and m 
does not lie in the same section as n, but if p' is any proper subpath of p and 

n n' , then n' lies in the same section as n. 

We can now see that each atom rooted at rig is of the form |{p : n m}] 
where m is an outcome for n. For if p,p' are two paths such that n — ^ m 

and n m, then they surely belong to the same atom. Since they re-join 
at m, no assignment to the remaining variables can cause p and p' to lead to 
different results. Moreover, if two paths lead to different outcomes, then by the 
extensionality principle for reduced bdds, there must be some assignment to the 
remaining variables that separates them. 

2.16 An Algorithm for Finding Atoms 

The analysis we have just carried out motivates an algorithm for finding atoms 
in a BDD that has been divided into sections like Figure 3, where the sections 
consist of the source address variables, the destination address variables, and the 
protocol-specific variables. The two sinks lie below all three sections. 

The algorithm maintains a hash table h that associates each outcome with 
the paths that lead to it. The algorithm has two phases. Phase one traverses 
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the BDD rooted at no, and phase two traverses the hash table. In phase one, we 
recursively descend the bdd. If the node n at the end of the current path p is 
an outcome for no, then: 

If h contains an entry s for n, then the new entry for n in h is {p} U s; 
Otherwise the initial entry for n in h is the singleton {p}. 

If n is not yet an outcome, recursively consider both extensions of the path p. 

In phase two, we walk the hash table h. Each entry associates an outcome 
node n with the set s of paths leading from no to n. Each entry determines an 
atom with value |s]. Since every path from no must eventually leave the section, 
each path reaches some outcome, which entails that the union of all the atoms is 
exhaustive. The atoms are mutually exclusive because any path reaches at most 
one outcome. Thus, we have derived a partition of the set of source addresses. 

As described, this algorithm discovers the source atoms, those sets of source 
addresses that are treated the same by a single filter, when appearing as ip packet 
sources. The destination atoms may be calculated in the same way, starting from 
each outcome n that arose in finding the source atoms. Each outcome n leads 
to a list of destination atoms, containing those destination addresses that are 
treated the same starting from n. The algorithm is executed once starting for 
each source outcome n, each time yielding some destination outcomes. Finally, 
service atoms may be discovered starting from each of these destination-atom 
outcomes; in calculating the service atoms, the remaining outcomes can only be 
the two sinks true and false. 

2.17 Source and Destination Addresses, Multiple Filters 

So far, we have computed a partition of the set of source addresses; a family 
of partitions of the set of destination addresses, starting from various source- 
atom outcomes; and a similar family of partitions of services. This calculation 
analyzes a single filter. Several filters may be defined for different interfaces (and 
opposite directions of traversal) within the same configuration file, and several 
configuration files for different routers may need to be analyzed. How do we put 
all of these pieces together? Let us concentrate on constructing the right abstract 
addresses, the treatment of abstract services being essentially the same. 

In essence, we have a number of partitions IFi of the ip addresses. Each parti- 
tion is a congruence with respect to one condition, such as the source addresses 
of packets passing through a particular filter, or the destination addresses, as- 
suming that the source led to a particular outcome. We call each of these families 
a family of pre- atoms. We want to construct a single partition of the ip addresses 
which is a congruence with respect to all of the conditions. It will thus be the 
coarsest common refinement of the J-i. 

To do so we must split the pre-atoms of J-i wherever the pre-atoms of J^j over- 
lap with them. Let Si G Ti and Sj € and define superimpose(si, Sj) to be 
either the tag None or the tag Some applied to a triple of sets: 

- None, if n Sj = 0; 
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— Some((si n Sj), {si \ sj), (sj \ Si)), otherwise. 

To add a single pre-atom Si to a list / representing a family of pre-atoms we 
recursively apply the following procedure: 

— If / is the empty list [ ], then the result is the singleton list [s^]. 

— Otherwise, / is of the form Sj :: rest. If the result of superimposing Si on Sj 
is None, recursively add Si to rest, obtaining /', and return Sj 

— If the result of superimposing Si on Sj is Some(c, s', s' ), then recursively 
add s' to rest, obtaining /', and return c :: s' :: /'. 

Finally, if we have two families, represented as lists /i and / 2 , then to combine 
them: 

— If /i is the empty list [ ] , then return / 2 . 

— Otherwise, fi is of the form si :: rest. Recursively, combine rest with f^, and 
then add the single pre-atom si to the result (as defined above). 

2.18 Atomizer Results 

The Atomizer has been implemented as a rather large program written in OCaml, 
an implementation of ML developed at INRIA/Rocquencourt [25]. When run 
against a set of three unusually large configuration files in actual use, containing 
1380 lines of access lists, it constructs about a hundred atoms. Computation 
takes 29 seconds on a 550MHz Pentium ill with 700MB of store. The maximum 
process size is 58MB of store. The bulk of the space seems to be devoted to 
storing the bdds, so that re-implementing that data structure in C (which is 
accessible from OCaml) would probably reduce the space used significantly. 

When run against even larger but artificially generated configuration files, 
containing 5,575 lines of access lists, it completes in 20.5 seconds, having occupied 
45MB of store. 

The Atomizer generates abstract addresses and abstract services to be used 
in NPT, thus providing a method for analyzing actual router configurations to 
discover the security goals that they jointly achieve in use. 

2.19 Packet Trajectories and Security Management 

In this section, we have modeled the trajectories that packets may take through 
networks. We regard the networks as bipartite graphs, in which a node is ei- 
ther a router (used as an enforcement point) or a network area. Edges represent 
a router’s interface on a network area. The packets that can survive all of the 
filters on a particular path form the feasibility set for that path. Given an im- 
plementation for boolean algebras and their fundamental operations, we can 
calculate feasibility sets, and use them to answer questions. We described an al- 
gorithm to determine whether a given posture meets a security policy. Another 
algorithm constructs a posture that will meet a security policy. We also described 
an algorithm that uses binary decision diagrams to determine (from a number of 
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actual configuration files) the atoms that will be needed in the boolean algebra 
for these computations. 

Thus, this approach to modeling allows us to answer a number of different 
security management questions about our networks. In the introduction, we 
enumerated some crucial security management questions. Let us return to that 
list, and comment on the extent to which our methods, as described in this 
section, give answers to them, in the specific context of packet filtering. 

1. Does a given system meet a particular security goal? 

If the system is described in terms of the abstract packets passed or discarded 
at the different filtering points, then NPT answers this question. 

2. Given a system, what security goals does it meet? 

We use the Atomizer to construct a suitable boolean algebra and represen- 
tations of the filters. Then, given any two areas a, a', we can calculate the 
union of the feasibility sets ^or all p such that po = a and p|p| = a'. 

This union is the most inclusive security policy enforced by these filters. 

3. Given a security goal, how can we configure (or modify) a system to meet 
it? 

We have described how to use NPT to calculate a posture to enforce the 
policy. We have not, however, described an algorithm to construct a (pro- 
cedural, Gisco-style) configuration file from a list-of-rectangles specification 
for a filter, or from a bdd representing it, although work has been done in 
this direction. 

4. Given a real-world system, how can we construct the abstraction that models 
it? 

Network mapping tools may be used to construct the bipartite graph for the 
system, after which the Atomizer designs the necessary abstractions for the 
filters. 

5. Given a real-world system, what automated tests (or manual analysis) will 
check whether a given abstraction models it faithfully? Whether a given 
security goal has been violated? 

Our methods can be used to discover what packets are expected to emerge 
from a given interface; by sniffing the network and sampling the headers, we 
can raise an alarm if an unexpected packet is found. See also [22], in which 
specifications are used to generate test cases systematically. 

6. If two given systems each meet a security goal, does each continue to meet 
that security goal if they are combined in a particular way? 

NPT can be used to determine the security consequence of adding direct 
network connections between previously distant areas. 

Thus, we have illustrated in some breadth how to specify and reason about net- 
wide security policies for filtering routers, providing an instance of the rigorous 
approach to security management. 

3 Strand Spaces and Protocol Security Goals 

In the remainder of this series of lectures, we will discuss cryptographic protocols. 
We would like to define a particular type of failure, and the class of security goals 
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that rule out these failures. We will explain our modeling for cryptographic 
protocols and their security goals in this section, and illustrate how to use the 
modeling ideas to detect flaws in protocols that have them. In Section 4 we will 
give a more rigorous treatment, leading to a simple method for proving that keys 
are not disclosed. Section 5 focuses on how to prove authentication goals. Finally, 
in Section 6, we will explain how to determine whether mixing two protocols will 
cause interactions that will undermine their (separate) security guarantees. 

3.1 What is a Cryptographic Protocol? 

A cryptographic protocol is a short, convention-bound sequence of messages. It 
uses cryptography to aim at security services such as authentication and key 
distribution (or key agreement) for session keys. 

Despite their simplicity, cryptographic protocols are frequently wrong. Lowe 
estimates that about half the protocols published fail to achieve their goals in 
some respect [28]. Since this comment concerns only published, peer-reviewed 
protocols, one may imagine that the success rate for proprietary protocols would 
be lower. However, as a consequence of intense work on this problem, including 
apparently hundreds of published papers,^ the quality of newer protocols such 
as SSH [50] and tls [8] seems much better. 

The problem is tricky because an attacker (“the penetrator”) can be an 
active participant on the network itself. The attacker can start sessions with 
other principals, or wait for them to start sessions with each other or with 
the attacker (not realizing that the attacker is malicious). The penetrator can 
encrypt or decrypt using public keys, or legitimately obtained secret keys, or 
stolen keys, or keys extracted from messages. The penetrator can prevent the 
regular participants from receiving messages, and can substitute messages of his 
own. 

3.2 The Dolev-Yao Problem 

Because of this collection of potential tricks, it is difficult to see what the pen- 
etrator can accomplish. Indeed, the penetrator can sometimes undermine the 
goals of a protocol without any cryptanalysis. The attacks would succeed even 
if the protocol was implemented with ideal cryptography. The idea of studying 
protocol correctness without regard to cryptographic flaws is due to Dolev and 
Yao [9]. 

The terminology of correctness and flaws is, however, too crude. The question 
is really what security goals a cryptographic protocol can achieve. A “flaw” is 
a counterexample that shows that a protocol does not achieve some goal that 
we thought it should meet. A correct protocol is one that achieves specific goals 
that we find useful. 

^ See [6] for an extensive bibliography through the mid-nineties. Indeed, the present 
chapter has 50 citations, despite not citing large numbers of papers in the literature. 
For instance, we do not even cite [4], let alone the hordes of papers derived from it. 
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Thus, a more nuanced way to state the Dolev-Yao problem is, to determine, 
given a cryptographic protocol, what security goals it achieves, and to find coun- 
terexamples showing why it does not meet other goals. In doing so, one assumes 
that the cryptography in use is ideal, meaning that one cannot determine any- 
thing about plaintext from ciphertext, or anything about ciphertext from plain- 
text, without possessing the decryption or encryption key (respectively). 

The problem is important, because cryptographic protocols are a central 
part of the infrastructure for secure communications and networking, and for 
distributed systems and electronic commerce. Their importance applies equally 
to military and civil systems. The Dolev-Yao approach of separating crypto- 
graphic issues from structural protocol flaws is valuable for two main reasons. 
First, it allows us to discover this class of flaws unencumbered by the complex- 
ity of cryptographic issues. Second, the same protocol can be implemented using 
a variety of different cryptographic algorithms; the Dolev-Yao approach tells us 
whether even the best adapted implementation can achieve its goals. 

3.3 An Example: The Needham-Schroeder Public Key Protocol 

The famous Needham-Schroeder article [37] introduced the idea of using crypto- 
graphic protocols to achieve authentication for networked systems. It discusses 
both secret-key and public- key protocols, and proposed one of each, both of 
which were problematic. Let us examine the public-key protocol. In this protocol 
(as presented here) each participant has the other’s public key, guaranteed us- 
ing some public-key infrastructure assumed reliable. The initiator A constructs 
a nonce — a randomly chosen bitstring — Na and transmits it to the recipient 
B accompanied by A’s name, encrypted in B's public key. B, if willing to have 
a conversation with A, replies with a nonce Nb of his own construction, accom- 
panied by Na and encrypted with A’s public key. Finally, A replies with TVf,, 
translated now into B's public key. This is summarized in Figure 4. We write 
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Fig. 4. The Needham-Schroeder protocol 



to mean the encryption of t by K, and tt' to mean the concatenation of t 
and t' . The protocol is intended to authenticate A and B to each other, and to 
assure them that they share the secret values Na and W. These values may be 
combined (for instance, using exclusive-or) for a symmetric session key. 



Security Goals: Packet Trajectories and Strand Spaces 221 



One of the most important parts of Figure 4 is the whitespace that separates 
the left side from the right side. The initiator A knows that on a particular 
occasion he sent {|7Va A^Kb ^^nd then received {|iVa Ni,^Ka: but he certainly does 
not know that B received the outgoing message and sent the reply. Otherwise, 
there would be no need for authentication. On the contrary, A needs to deduce 
from the way that the protocol is constructed, that if {|lVa came back, 

only B can have sent it, assuming that B's private key, is uncompromised. 

Protocol analysis is the art of inferring what others have done, knowing only 
what one has done oneself, and the laws of the protocol. 

Unfortunately, in this protocol, we cannot simply ignore the whitespace. 
There is another way that things can fit together, if a malicious penetrator 
is present, shown in Figure 5. The attack is due to Lowe [27], and was discovered 
a decade and a half after the protocol was published. A has initiated a session 
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Fig. 5. A bundle: penetrated run of Needham-Schroeder 



with a participant P who has decided to misbehave, possibly in response to this 
opportunity. As a consequence of A’s bad luck, B is duped. B believes that he 
shares the confidential values Na,Ni, with A, whereas messages encrypted with 
the resulting session key will come from P. 

A is not duped, because A intended to communicate with P and has done 
so. B is duped, because B believes that A is sending messages to B using the 
resulting session key, whereas P is doing so. Secrecy has failed, because the 
nonces and session key are known to P, and authentication has failed, because 
A has no run of the protocol intended for B, whereas B has a run apparently 
with A. How has this situation come about? 

3.4 Unintended Services 

The protocol itself imposes an obligation on A, when A starts a run as initiator, 
with responder P. A transmits a value Na, and then undertakes to provide a 
service. If a value of the form {jA’a N^Ka is presented (for any N), then A will 
perform a translation. A will translate N into the form {|?V[}-;fp. Thus, N is 
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retransmitted in a form that P can read. We call this an unintended service, 
because the protocol requires initiators to perform it, despite its being potentially 
useful to penetrators. 

Indeed, getting iV in a readable form is particularly useful to a penetrator, 
and the reason for this becomes clear when we consider how the responder B gets 
his authentication guarantee. B can get a guarantee that A is executing his 
matching run only by receiving some message from B that only A can produce, 
and only in a matching run. 

If we look at B's behavior, he receives only two messages. The first message 
is of the form A^Kb- Since Kb is public, anyone can create a nonce N, 
concatenate it with A’s name, and encode it with the public key. Therefore, 
from the point of view of its authenticating force, this message is mere junk. It 
contributes to no guarantee. Thus, any authenticating force is concentrated in 
the last message ^Ni,^Kb- 

Thus, we may examine a principal’s incoming messages to determine which 
are junk. Discarding the junk messages, we are left with the other messages, 
those capable of providing authenticating force. We then examine the protocol to 
see what unintended services it provides, and whether these unintended services 
suffice to counterfeit the non-junk messages. This is a practical recipe for informal 
protocol analysis. 



3.5 Another Example: An ISO Candidate 

The protocol shown in Figure 6 was a candidate considered by an ISO committee 
as a pure authentication protocol. No shared secret is achieved. It was intended 
merely to assure each principal that the expected partner was initiating commu- 
nications. In this protocol A uses his private key to sign nonces passed to B, 
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Fig. 6. An ISO candidate protocol 



and conversely. Considering how A may authenticate itself to B, clearly the first, 
unsigned message is junk. Thus, the last message {| A' TVf, contains any 

authenticating force. Thus, we want to look for unintended services that would 
create a value of this form. 

The possible services are the two transformations shown in Figure 7. In these 
services, any variables originating in incoming messages may be freely renamed. 
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Those originating on outgoing messages, by contrast, are created by the princi- 
pal, and therefore cannot be manipulated by the penetrator. Now if A is active 
as a responder, and is presented with the values B Nf, in the incoming message, 
then the target term Nf, will be the result. 
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Fig. 7. Unintended services in the ISO candidate 



The resulting attack is shown in Figure 8. Since it was discovered by the 
Canadian representatives to the committee, it is sometimes called the Canadian 
attack. To discover this attack, we discarded junk messages and focused on the 
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Fig. 8. The Canadian attack 



remaining non-junk target. The unintended services provided by the protocol 
then give us a recipe for generating our target message. In fact, it is easy to mul- 
tiply examples in which this method of junk messages and unintended services 
lead us to attacks. 

3.6 Types of Unintended Service 

There are effectively four types of unintended service that a protocol can offer 
to the penetrator. 
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Signature In a signature service, a protocol entity is required to sign messages 
containing an incoming ingredient. 

The transformation is Na i— > {| Na Hic-i- The Canadian attack of Sec- 
tion 3.5 is an example. 

Encryption In an encryption service, a protocol entity is required to encrypt 
messages containing an incoming ingredient. 

The transformation is Na > {| Na ^k- It frequently occurs in protocols 
in which the ability to encrypt using a symmetric key is used as an authen- 
ticating characteristic. 

Decryption In a decryption service, a protocol entity is required to decrypt 
messages containing an incoming ingredient. 

The transformation is {| Na ^ Na- This one does not occur in nature 
as far as I know; presumably it is too obviously a problem. 

Translation In a translation service, a protocol entity receives encrypted mes- 
sages and transmits some ingredients encrypted under a different key. 

The transformation is {| Na |}if H Na ^k'- Lowe’s attack on the 
Needham-Schroeder protocol is an example. 



3.7 The Dolev-Yao Problem Defined 

The Dolev-Yao problem is the following challenge. The player is presented with 
a cryptographic protocol. The player must then state the secrecy properties and 
authentication properties that the protocol achieves. He must also give counter- 
examples to any secrecy or authentication properties that he believes it does not 
achieve. 

In playing this game, the player is allowed to assume that cryptographic 
primitives will be chosen to be perfect. The primitives will never have collisions. 
The penetrator can infer nothing about plaintext, given a ciphertext, without 
using the key. Conversely, the penetrator can infer nothing about ciphertext, 
given a plaintext, without using the key. Moreover, the penetrator cannot learn 
a key, unless the key is contained in a message that the penetrator can decrypt. 

We have already explained how to play the second part of the game, the part 
where counter-examples must be given. The next section is devoted to explain- 
ing how to find and prove the secrecy and authentication properties protocols 
achieve. The remainder of this section will be devoted to defining our model of 
protocol execution, called the strand space model, and to defining what secrecy 
and authentication properties mean in this model. 

3.8 Strand Space Ideas 

We very briefly summarize the ideas behind the strand space model [47,16]; see 
also the definitions given in Section 3.14, which is an appendix to Section 3. 

A is the set of messages that can be sent between principals. We call elements 
of A terms. A is freely generated from two disjoint sets, T (representing texts 
such as nonces or names) and K (representing keys) by means of concatenation 
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and encryption. The concatenation of terms g and h is denoted g h, and the 
encryption of h using key K is denoted {|h|}^. (See Section 3.14.) 

A term t is a subterm of another term t' , written t IZ t' , if starting with t we 
can reach f by repeatedly concatenating with arbitrary terms and encrypting 
with arbitrary keys. Hence, K [Zi {|t[l-if , except in case K Z t. The subterms of t 
are the values that are uttered when t is sent; in {|f[l-ic, K is not uttered but 
used. (See Definition 6.) 

A strand is a sequence of message transmissions and receptions, where trans- 
mission of a term t is represented as +t and reception of term t is represented 
as —t. A strand element is called a node. If s is a strand, {s,i) is the node 
on s. The relation n ^ n' holds between nodes n and n' if n = (s,i) and 
n' = (s,j -|- 1). Hence, n n' means that n = {s,i) and n' = {s,j) for some 
j > i. Each column of nodes connected by vertical arrows in Figures 4-8 is 
a strand. 

The relation n — > n' represents inter-strand communication; it means that 
term(ni) = +t and node term(ri 2 ) = —t. Inter-strand communication is shown 
by horizontal arrows — *■ in Figures 5-8. 

A strand space A is a set of strands. The two relations and — > jointly 
impose a graph structure on the nodes of U. The vertices of this graph are the 
nodes, and the edges are the union of and — 

We say that a term t originates at a node n = (s,f) if the sign of n is 
positive; t Z term(n); and t [t term((s,i')) for every i' < i. Thus, n represents 
a message transmission that includes t, and it is the first node in s including t. 
For instance, A and Np originate at the top left node of Figure 8. If a value 
originates on only one node in the strand space, we call it uniquely originating- 
uniquely originating values are desirable as nonces and session keys. 

A bundle is a finite, causally well-founded collection of nodes and arrows of 
both kinds. In a bundle, when a strand receives a message to, there is a unique 
node transmitting to from which the message was immediately received. By 
contrast, when a strand transmits a message to, many strands (or none) may 
immediately receive to. (See Definition 3.) Figures 5 and 8 are examples of 
bundles; those examples happen to be undesirable. 

Since a bundle C is an acyclic directed graph, the reflexive, transitive closure 
of the arrows (^ together with ^^) form a partial order The statement 
w d:c means that there is a path from m to n traversing 0 or more arrows, 
in which both — > and may appear. Because C is finite, is a well-ordering, 
meaning that every non-empty set of nodes contains a ^c-minimal element. This 
is an induction principle, used extensively in [47]. 

The height of a strand in a bundle is the number of nodes on the strand that 
are in the bundle. Authentication theorems generally assert that a strand has 
at least a given height in some bundle, meaning that the principal must have 
engaged in at least that many steps of its run. 

A strand represents the local view of a participant in a run of a protocol. 
For a legitimate participant, it represents the messages that participant would 
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send or receive as part of one particular run of his side of the protocol. We call 
a strand representing a legitimate participant a regular strand. 

3.9 The Powers of the Penetrator 

For the penetrator, the strand represents an atomic deduction. More complex 
actions can be formed by connecting several penetrator strands. While regular 
principals are represented only by what they say and hear, the behavior of the 
penetrator is represented more explicitly, because the values he deduces are 
treated as if they had been said publicly. 

We partition penetrator strands according to the operations they exemplify. 
E-strands encrypt when given a key and a plaintext; D-strands decrypt when 
given a decryption key and matching ciphertext; C-strands and S-strands con- 
catenate and separate terms, respectively; K-strands emit keys from a set of 
known keys; and M-strands emit known atomic texts or guesses. A parameter to 
the model is the set Kp of keys known initially to the penetrator. It represents an 
assumption about what keys the penetrator may emit on K-strands, as opposed 
to getting them indirectly, for instance by decrypting a message containing a new 
session key. (See Definition 8.) 

As an example of how the penetrator can hook together several atomic 
strands to achieve a harmful compound effect, let us consider how the penetrator 
carries out his attack in Figure 5. To get from the incoming value {| A”a A^Kp to 
the outgoing value ^NaA^Kp: the penetrator must decrypt and then encrypt. To 
decrypt ^Na A^xn the penetrator must apply his (private) decryption key Kp^ . 
He obtains this directly, as it is assumed a member of the set K-p that he pos- 
sesses from the start. In the encryption that produces {| A(j A^Xb j the penetrator 
applies B’s public key. We my also assume that it is a member of the set Kp, 
because it is public knowledge. Thus, we may diagram the penetrator’s activity 
as shown in Figure 9. The lower column of penetrator activity in Figure 5 may 
be expanded similarly. 

3.10 Representing Protocols 

We turn now to the regular participants. Unlike the powers of the penetrator, 
which are the same regardless of the protocol, the behavior of the regular princi- 
pals is dictated by the protocol. We may assume that we already have a diagram 
describing the protocol, in the style of Figure 4. To define a protocol, we take 
three steps. We will illustrate these steps starting with the Carlsen protocol [5], 
the diagram for which is shown in Figure 10. 



Auxiliary Functions A public-key protocol typically requires a function as- 
sociating a public key with each principal. A symmetric-key protocol typically 
requires a function associating a long-term key, shared with a key server, with 
each principal. We typically write such functions using subscripts, with Ka be- 
ing the key associated with A, and refer to it as the “key-of” function. In the 
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Fig. 9. Penetrator activity in figure 5 




case of the Carlsen protocol, Ka represents the long-term key of A, shared with 
the key server. 

If a protocol uses a key server as Carlsen’s protocol does, then we will require 
that the session keys it chooses must be disjoint from the range of “key-of” 
function. 

Occasionally a protocol requires a different function, such as a function as- 
sociating a long-term shared secret with each pair of principals. 



Parametric Strands Next we define the strands for the protocol. To do this, we 
start from the columns shown in the diagram. Each separate column represents 
a different role. In the Carlsen protocol, they are initiator, responder, and key 
server. 

In some cases, there may be message components received a principal that 
it cannot check, because they are encrypted using a key that the recipient does 
not possess. These terms are simply forwarded to another principal. They will 
be represented simply by variables. The component (presumably) of the form 
^NaB K^Ka cannot be checked when it is received by B. B can only forward 
it to A. We will represent this component using the variable H. Other messages 
are represented by terms of the obvious form. 

By collecting the variables occurring in any term sent or received by that 
column, we find the parameters for that role. The parameters for the recipient 
are A, B, Na, Nt, K, iV^, H, while those for the initiator are A, B, Na, K, N^. The 
initiator never sees Nb, and never interprets an encrypted unit as H. The pa- 
rameters for the key server are A, B, Na, Nf,, K, since it never sees and never 
interprets an encrypted unit as H . We write: 

— Clmt[A, B , Na, K, Nl^] is the set of strands with trace (behavior): 



+ANa, -^NaBK^KA^a^KN', 
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Fig. 10. Carlsen’s protocol 



This means that first a message is sent containing A and Na, and then 
a message is received containing the nonce Na again, encrypted in A’s long- 
term key, and so on. 

— CResp[^, B, Na, Nb, K, H] is the set of strands with trace 



-ANa, +ANaBNb, -^KNbA^KsH, + H ^NaU K -Wk 
— CServ[^, B, Na,Nt, K] is the set of strands with trace 



We write * in particular argument positions to indicate a union. For instance. 



is the set of all initiator strands involving A and B, with any nonces and session 
keys. We also use ** to indicate that multiple adjacent arguments have been 
projected, writing e.g. CInit[^, B, **] for CInit[A, B, *, *, *]. 

The regular strands are generated by filling in the parameters with appro- 
priate values. Instantiations may be limited to subtypes of the message alge- 
bra. For instance, the parameters A and B may be instantiated with any value 
that names a principal (perhaps these are ip addresses or X.509 Distinguished 
Names); Na may be instantiated with any bitstring of length 128; and so on. 
We assume that there is some association D of variables with sets of terms in A. 
Very often it is convenient to assume some of these sets are disjoint, for instance 
the sets D{Na), D{K), D{A) of nonces, keys, and names (respectively). 

Often, a strand space contains strands belonging to a parametric strand 
whenever the instantiation is type-correct. For instance, in the case of a para- 
metric strand such as CServ[A, B, Na, Nb, K], if a € D{A), b G D{B), Ua G 



ANaBNb, +^KNbA\^KANaBK^Ki 



CInit[A, B, *,*,*] = y Clmi[A,B,Na,K,Ni;\ 



Na^K.Nl^ 
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D{Na), Ub S D{Nb), and k € D{K), then CServ[a, 6, tIq, rib, fc] is non-empty. 
Sometimes it is convenient to stipulate that variables get distinct instantiations. 
For instance, in our formalization of the Needham-Schroeder-Lowe responder’s 
guarantee (see below, Section 3.12 and [47,16]) we assume that the responder’s 
nonce Nb is different from the initiator’s nonce Na- This may be encoded into 
the strand space itself by stipulating that NSLResp[a, &, ria, nt] is non-empty 
whenever a G D{A), b G D{B), Ua G D{Na), Ub G D{Nb), and ^ Ub- 



Restricted Values There are also some additional restrictions on the way 
that the values are used. For instance, in the case of the Carlsen protocol, the 
values Na, Nb, and are nonces. This means that they are intended to originate 
uniquely. The session keys K are also intended to originate uniquely, as well as 
to be disjoint from the long-term keys. Correctness goals may also depend on 
the assumption that the player’s long-term keys are not in Kp, the penetrator’s 
initial knowledge, compromised through nefarious means or lucky guessing. This 
assumption is unavoidable, in that, when Ka G K-p, the key server and B can 
have no assurance that A has done anything, or that session keys destined for 
A remain secret. 

In this protocol, the assumption that Ka ^ Kp is also an origination assump- 
tion. It amounts to the assumption that Ka will originate nowhere. It entails 
that Ka does not originate on a penetrator K-strand. No key originates on an 
initiator or responder strand in this protocol. And we have assumed that the 
session keys originating at the key server are disjoint from the long-term keys. 

Origination restrictions are of course implemented using probabilistic mech- 
anisms in reality, and some work has been done on quantifying the extent to 
which a particular implementation is reliable [17]. 

3.11 Unique Origination and Non-origination 

The value Na originates on the first node of any strand s G CInit[*, *, Na, *, *]• 
What we mean by this is that a message is sent on that node, and the message 
contains Na, and that this is the first node on the strand containing Na- By 
contrast, Nj^ does not originate on the third node of any s G CInit[**, iV^], 
because although a message is sent on that node and that message contains 7V^, 
the previous (receiving) node also contained 

We say that a term t originates uniquely in a bundle C if there is exactly 
one node n in C such that t originates on n. When there is no node on which 
t originates, we say that t is non-originating in C. 

In particular, Ka does not originate on s S CServ[A, **], because although 
a term encrypted with Ka is sent on the second node of s, and Ka has not been 
used previously, Ka is not a subterm of the message. It contributes to how the 
term is constructed, but not what the term contains, and this is the intuition 
formalized in our definition of subterm (Definition 6). 

Assumptions about unique origination and non-origination are a way of re- 
stricting what attacks on a protocol we are willing to worry about. For instance. 
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in Figure 11 we illustrate an “attack” on the Needham-Schroeder protocol in 
which the penetrator simply somehow knows what the responder’s nonce N}, is. 
While this could conceivably happen, it is not a strategy likely to succeed for 



Fig. 11. An improbable attack: guessing a Needham-Schroeder nonce 

the penetrator. Protocol design, therefore, does not need to concern itself sys- 
tematically with how to prevent it. 

A bundle describes what happens when a protocol runs, and in this we follow 
Robert Lowell’s maxim, “Why not say what happened?” A bundle may contain 
some regular strands and some penetrator strands. The events of sending and re- 
ceiving messages are connected in a causally well-founded way. We are concerned 
with a particular bundle only if it satisfies some unique origination conditions 
and some non-origination assumptions; otherwise, things may go wrong, but it 
is too implausible an attack. 

3.12 What Is an Authentication Goal? 

Strands are a suggestive formalism for understanding authentication and au- 
thentication failures. A strand represents one principal’s experience of a protocol 
execution. The strand includes the information that the principal knows directly, 
namely that it sent certain messages and received other messages, in a particular 
order. Security goals for protocols concern what else must also have happened. 
Authentication goals are about what another regular principal must have done. 
Secrecy goals are inferences about what the penetrator cannot have done. 

Let us return to the Needham-Schroeder protocol to consider what authen- 
tication goals are, in the light of the failure illustrated in Figure 5. One of the 
goals of the protocol is to assure the responder B, 

For every R-strand (apparently with A), 
there is an A-strand (apparently with R), 
and they agree on the nonces Na, 

^ It is sometimes said that this was not a goal of the protocol as originally described, 
but that the protocol was intended only to establish that A was active. That is. 
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The attack shows that there can be a i?-strand, apparently with A, without 
any ^-strand apparently with B. 

This example is typical. An authentication result justifies a sound inference, 
and a counterexample to an authentication property shows that the inference 
is unsound. From B’s local experience, a conclusion about A’s behavior should 
follow. Naturally, there are assumptions that must be met for the inference to 
hold good, and protocol analysis is informative because it identifies exactly what 
the assumptions are. 

When we consider the epistemology of authentication protocols, that is, the 
theory of knowledge that applies to them, there are four ingredients. First, there 
are the facts that a principal knows, which is to say the message sends and 
receives belonging to a single strand. Second, there are the conventions of the 
protocol, which dictate that the behavior of other regular participants will be 
described by the strands of the protocol. Third, there is the model of the pen- 
etrator embodied in Definition 8. Finally, there assumptions about origination: 
the unique origination of nonces and session keys, and the non-origination of 
long-term secrets. 

From these elements, we try to infer what other events have occurred. The 
real world (the bundle) must contain events that causally explain what we saw. 
To find out what these events could be, we use the causal laws embodied in the 
definition of bundle (Definition 3). We may use these principles: 

— What is heard was said, i.e. every negative node has a unique in-arrow in 
the bundle C; 

— Every principal starts at the beginning, i.e. if n G C, and m n precedes it 
on the same strand, then m G C; 

— Causality is acyclic, and bundles are finite. 

From the last of these, an induction principle follows. Namely, if is defined as 
the reflexive, transitive closure of the union of the two kinds of arrows, — *■ and 
then every non-empty set S of nodes in C has a precegc-minimal member. 
If S' is a set of nodes at which the penetrator possesses some dangerous value, 
then a minimal member of S pinpoints how the penetrator learnt it. The maxim 
here, as in Watergate, is, “What did he know and when did he know it?” 

To illustrate an authentication goal, let us switch now to a protocol that 
achieves its goals, such as the Needham-Schroeder-Lowe protocol [27] as shown 
in Figure 12. The only difference from the Needham-Schroeder protocol is in the 
second message ^Na Nb B^Ka, in which the responder includes his name. This 
prevents the attack shown in Figure 5. We use NSLInit[A, B, Na, A^b] to refer to 
the set of all strands having the behavior shown in the left column of Figure 12, 

there should be an A-strand with some partner. The protocol does in fact achieve 
this. 

However, unless the goal of the protocol is the stronger assertion we have given, 
and the nonces are intended to become a shared secret between A and B, it is hard 
to see why the last message should be the encrypted value {jNbOifB. The plaintext 
message Ns would also achieve the weaker goal. 
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Fig. 12. Needham-Schroeder-Lowe protocol 



while NSLResp[A, B, Na, -/V^] refers to the set of all strands having the behavior 
shown in the right column. 

In the revised Needham-Schroeder-Lowe, the responder B can in fact be sure 
that the initiator A wanted to execute a run with B. This means that in any 
bundle C containing a responder strand Sr G NSLResp[A, R, TV^, TVf,], there is 
an initiator strand Si G NSLInit[^, R, N{,] contained in C (subject to some 
origination assumptions). In fact [47], the assumptions needed are 

— Nb is uniquely originating in C and Nb ^ Na, and 

— is non-originating in C (or alternatively, ^ Kp). 

In the case of the initiator’s guarantee, the situation is slightly different. Since the 
initiator sends the last message, the initiator can certainly never know whether 
the responder receives it. Thus, the only reasonable goal is to show that the first 
two nodes of the responder’s strand are in the bundle C. We express this by 
saying that the strand has C-height at least 2 (see Definition 4). The initiator’s 
guarantee states that if 

~ Na is uniquely originating in C; and 

— and are non-originating in C 

(or alternatively, ^ K-p) 

and Si € NSLInit[A, R, TVa, has C-height 2, 
then some Sr G NSLResp[A, R, TVq, has C-height 2. 

It is an unexpected asymmetry of the Needham-Schroeder-Lowe protocol 
that the initiator’s guarantee depends on both participants’ private keys being 
imcompromised, while the responder’s guarantee depends only on one private 
key being uncompromised. 

In some cases, not all data values are authenticated between the principals. 
For instance, in the Carlsen protocol (Figure 10), the initiator never sees the 
responder’s first nonce Nb- Thus, the conclusion of the initiator’s guarantee can 
specify only that Sr G CResp[A, B,Na,*,K, . . 

We can now give the logical form of an authentication goal. Authentication 
goals always take the form: for all bundles C and all strands s, there exists 
a strand s' such that 

If some origination assumptions hold, 
and s G R has C-height i, 
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then s' € R' and s' has C-height j. 

In this, R and R' are role predicates (or “asterisked” unions over role predi- 
cates), such as NSLInit[A, B, Na, Nf,] and CResp[^, B, Na, *, K, Nl^, *]. An orig- 
ination assumption always concerns either a parameter X mentioned in R, or 
else Kx where X is a parameter mentioned in R. 

Analyzing the authentication properties of a protocol means finding the right 
choices for R and R' , for i and j, and the necessary origination assumptions. 

Many different goals can be stated and proved (or refuted) within our frame- 
work. For instance, Gollmann has said that Lowe’s attack does not undermine the 
claims made by Needham and Schroeder themselves, because they were work- 
ing in a context where they assumed that all the principals with whom one 
might want to talk are trustworthy. Of course, in a world of open networks and 
widespread electronic commerce, this would not be a reasonable assumption, but 
such a world was remote in 1978 when their article was published. 

Their authentication goal may be stated as follows. Let us say that X is 
an interlocutor in a bundle C if there exists a strand s G C such that s € 
NSInit[*, A, **] or s € NSResp[A, **]. Then the intended Needham-Schroeder 
authentication result simply has the additional assumption that for every inter- 
locutor X, is non-originating in C. The responder’s authentication goal is 
sound with this additional assumption. 

3.13 What Is a Secrecy Goal? 

Secrecy goals are loosely dual to authentication goals. While authentication goals 
assert that j nodes of some strand s' G R' have happened in the bundle C, 
secrecy goals say that nodes of a certain form do not occur in the bundle. Like 
authentication goals, they may depend on assumptions about origination. For 
instance, in the Needham-Schroeder-Lowe protocol, we want to ensure that there 
is no node in the bundle (even a penetrator node) where the message is Na or W. 
The result takes the form: For all bundles C, strands Si,Sr, and nodes n £ C 

If Si G NSLInit[A, R, A{,] and Sr G NSLResp[A, R, Wq, Wb] have C-height 
at least 1 and 2 respectively, 
and Na and Nj, are uniquely originating in C, and 
and and are non-originating in C, 

then term(n) yf Na and term(n) yf N},. 

Naturally, if we prove that Na and W are not said in public in any bundle C, 
then it follows that the penetrator cannot derive them from what he sees. If he 
could derive them, then there would exist a bundle in which he also (perhaps 
imprudently) utters them. 

Secrecy goals always take the form: for all bundles C and all strands s 

If some origination assumptions hold, 
and s G R has C-height i, 

then there is no node n G C such that term(n) = t. 
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Again, the origination assumptions concern parameters to R or values Kx where 
A is a parameter to R. The term t is a parameter to R, or a term constructed 
from parameters to R. 

We can call the role R in a secrecy or authentication goal the core role 
of the goal, since the principal playing role R receives the assurance that the 
peer is active, or that the secret has not been disclosed. Thus, the origination 
assumptions always concern parameters to the core role. 



Summary of this Section In this section, we have studied cryptographic 
protocols. We started by explaining the Dolev-Yao problem. We illustrated how 
to find flaws in protocols, even assuming that the cryptography by which they are 
implemented is perfect. One important insight for finding flaws is that we may 
ignore junk messages; the other one is that we want to examine the protocol to 
find the unintended services that may allow the penetrator to construct the non- 
junk messages that are intended to provide authenticating force to the regular 
principals. We then described how to formalize protocol behaviors using strand 
spaces; possible executions are bundles. Finally, we defined the logical forms of 
authentication and secrecy goals. We have thus illustrated two of the themes 
mentioned in the introduction, namely modeling security problems using simple 
mathematical materials, and defining specific classes of security properties to 
formalize real-world security goals. 

3.14 Appendix: Strand Space Definitions 

In this appendix to Section 3, we will define the basic strand space notions. 
This material is derived from [47,16]. The definitions of unique origination and 
non-origination (Definition 2, Clause 8) have been relativized to a bundle here, 
however. We also stipulate that a strand space has all the penetrator strands 
that it can (Definition 8). 



Strand Spaces Consider a set A, the elements of which are the possible mes- 
sages that can be exchanged between principals in a protocol. We will refer to 
the elements of A as terms. We assume that a subterm relation is defined on A. 
to C ti means to is a subterm of ti. We constrain the set A further below in 
Section 3.14, and define a subterm relation there. 

In a protocol, principals can either send or receive terms. We represent trans- 
mission of a term as the occurrence of that term with positive sign, and reception 
of a term as its occurrence with negative sign. 

Definition 1. A signed term is a pair {a, a) with a € A and a one of the 
symbols -k,— . We will write a signed term as +t or —t. (±A)* is the set of 
finite sequences of signed terms. We will denote a typical element of (±A)* by 
((cTi,ai), ..., {an, an)). 

A strand space over A is a set E with a trace mapping tr : A — > (±A)*. 
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By abuse of language, we will still treat signed terms as ordinary terms. For 
instance, we shall refer to subterms of signed terms. We will usually represent 
a strand space by its underlying set of strands E. 

Definition 2. Fix a strand space E. 

1. A node is a pair {s,i), with s G E and i an integer satisfying 1 < i < 
length{tr{s)) . The set of nodes is denoted hyJV. We will say the node {s,i) 
belongs to the strand s. Clearly, every node belongs to a unique strand. 

2. If n = (s,i) € JV then indexfn) = i and strandfn) = s. Define term{n) to be 
(ir(s))j, i.e. the ith signed term in the trace of s. Similarly, unsJ,erm(n) is 
((tr(s))j 2 ; *-e- the unsigned part of the ith signed term in the trace of s. 

3. There is an edge n\ ri 2 if and only if termini) = +a and term(ri 2 ) = 
—a for some a € A. Intuitively, the edge means that node n\ sends the 
message a, which is received by U 2 , recording a potential causal link between 
those strands. 

4-. When ni = (s, i) and U 2 = (s, z + 1) are members of N , there is an edge n\ 

U 2 . Intuitively, the edge expresses thatni is an immediate causal predecessor 
of U 2 on the strand s. We write n' n to mean that n' precedes n (not 
necessarily immediately) on the same strand. 

5. An unsigned term t occurs in n G Af iff t n. term{n) . 

6. Suppose I is a set of unsigned terms. The node n ^ Af is an entry point 
for I iff term{n) = +t for some t G I , and whenever n' =!>"'■ n, term{n') (fl. 

7. An unsigned term t originates on n G A/ iff n is an entry point for the set 
I={T :tnF}. 

8. An unsigned term t is uniquely originating in a set of nodes S G Af iff there 
is a unique n G S such that t originates on n. 

9. An unsigned term t is non-originating in a set of nodes S G AT iff there is 
no n G S such that t originates on n. 

If a term t originates uniquely in a suitable set of nodes, then it can play the role 
of a nonce or session key, assuming that everything that the penetrator does in 
some scenario is in that set of nodes. 

Af together with both sets of edges n\ — > H 2 and m ri 2 is a directed graph 

(Af,HU^)). 

Bundles and Causal Precedence A bundle is a finite subgraph of {Af, 

U =>)), for which we can regard the edges as expressing the causal dependencies 
of the nodes. 

Definition 3. Suppose — >c C — suppose C and suppose C = {Nc, (— 

U =^c)) is a subgraph of {Af, U =!>)). C is a bundle if: 

1. Afc 0 ,'nd — *-c U finite. 

2. If U 2 G Afc term(rL 2 ) is negative, then there is a unique ni such that 
ni — >c n2. 

3. If U 2 G Afc o>nd m ri 2 then n\ =^c n 2 . 
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4- C is acyclic. 

In conditions 2 and 3, it follows that m G Nc, because C is a graph. 

For our purposes, it does not matter whether communication is regarded as 
a synchronizing event or as an asynchronous activity. The definition of bundle 
formalizes a process communication model with three properties: 

— A strand (process) may send and receive messages, but not both at the same 
time; 

— When a strand receives a message t, there is a unique node transmitting 
t from which the message was immediately received; 

— If a strand transmits a message t, many strands may immediately receive t. 

Definition 4. A node n is in a bundle C = {Afc,->-c U =^c); written n € C, if 
n G A/”c ; a strand s is in C if all of its nodes are in Me ■ 

If C is a bundle, then the C-height of a strand s is the largest i such that 
(s,i) G C. C-trace(s) = (tr(s)(l), . . . , tr(s)(m)), where m = C-height(s). 

We say that s € C if the C-height of s equals length{s). 

Definition 5. If S is a set of edges, i.e. S C— > U =^, then is the transitive 

closure ofS, and ^5 is the reflexive, transitive closure of S. 

The relations -<s and <s are each subsets of Ms x Ms, where Ms is the set of 
nodes incident with any edge in S. 

Proposition 1 Suppose C is a bundle. Then <c is a partial order, i.e. a reflex- 
ive, antisymmetric, transitive relation. Every non-empty subset of the nodes in 
C has :<c -minimal members. 

We regard as expressing causal precedence, because n ~<s n' holds only 
when n’s occurrence causally contributes to the occurrence of n'. When a bun- 
dle C is understood, we will simply write Similarly, “minimal” will mean 
^C-nainimal. 

Terms, Encryption, and Preeness Assumptions We will now specialize the 
set of terms A. In particular we will assume given: 

— A set T C A of texts (representing the atomic messages). 

— A set K C A of cryptographic keys disjoint from T, equipped with a unary 
operator inv : K — *■ K. We assume that inv is an inverse mapping each 
member of a key pair for an asymmetric cryptosystem to the other, and 
each symmetric key to itself. 

— Two binary operators encr : K x A — > A and join : A x A ^ A. 

We follow custom and write inv(A) as K~^, encr{K, m) as {|m[}-ic, and join(a, b) 
as a 6. If A is a set of keys, denotes the set of inverses of elements of A. We 
assume, like many others (e.g. [29,32,39]), that A is freely generated, which is 
crucial for the results in this paper. 
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Axiom 1 A is freely generated from T and K by encr and join. 

Definition 6. The subterm relation C is defined inductively, as the smallest 
relation such that a \Z a; a n if a n g; and a\Zghifa\Zg or a \Z h. 

By this definition, for K G K, we have K \Z ^g^K only if K \Z g already. 

Definition 7. 1. If R CZ K, then tQ [_ t if t is in the smallest set containing tQ 

and closed under encryption with K € A and concatenation with arbitrary 
terms ti . 

2. A term t is simple if it is not of the form g h. 

3. A term to is a component oft if to is simple and to C 0 t. 

Penetrator Strands The atomic actions available to the penetrator are en- 
coded in a set of penetrator traces. They summarize his ability to discard mes- 
sages, generate well known messages, piece messages together, and apply cryp- 
tographic operations using keys that become available to him. A protocol attack 
typically requires hooking together several of these atomic actions. 

The actions available to the penetrator are relative to the set of keys that the 
penetrator knows initially. We encode this in a parameter, the set of penetrator 
keys K-p. 

Definition 8. A penetrator trace relative to K-p is one of the following: 

M( Text message: (+t) where t G T. 

Kk Key: {+K) where K G Kp. 

Cg,h Concatenation: {—g, —h, +gh) 

Sg^h Separation: {—g h, +g, +h) 

Eh,K Encryption: {-K, -h, 

Dh,K Decryption: -^h^K, +h) . 

Vs is the set of all strands s G E such that tr(s) is a penetrator trace. 

We assume that Vs contains instances of a penetrator strand type, whenever 
the instantiation is type-correct, and (in the case of a K-strand) the key K G Kp. 

A strand s G 27 is a penetrator strand if it belongs to Vs, and a node is a 
penetrator node if the strand it lies on is a penetrator strand. Otherwise we will 
call it a non-penetrator or regular strand or node. A node n is M, C, etc. node 
if n lies on a penetrator strand with a trace of kind M, C, etc. 

4 Paths and Well-Behaved Bundles 

In this section we will study the notion of bundle, focusing on a particular 
equivalence relation on them, and on the paths that messages and their con- 
stituents take through bundles. In certain “well-behaved” bundles, the paths are 
especially predictable, and in fact every bundle has an equivalent well-behaved 
bundle. This section will illustrate the advantages of the strand space model over 
closely related alternatives [40,43], at least as a heuristic for discovering results 
about cryptographic protocols. 
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4.1 Bundle Equivalence 

Definition 9. Bundles C,C' on a strand space E are equivalent iff 

1. they have the same regular nodes; 

2. for all a, a originates uniquely and on a regular node in C if and only if 
a originates uniquely and on a regular node in C ; 

3. for all a, a is non-originating in C iff a is non- originating in C . 

A set (j) of bundles is invariant under bundle equivalences if whenever bundles 
C and C are equivalent, C G 4> ^ C' G 4>. 

The penetrator’s behavior may differ arbitrarily between two bundles that are 
equivalent in this sense, and the orderings ;<c and :<c> may also differ freely. 

Authentication goals as defined in Section 3.12 are invariant under bundle 
equivalences in this sense (see also [30,47,49]). As such, it always concerns what 
nodes, representing regular activity of the protocol, must be present in bundles. 
Penetrator activity may or may not be present. 

Secrecy properties may also be expressed in a form that is invariant under 
bundle equivalences. We say (temporarily) that a value t is uncompromised in 
C if for every C' equivalent to C, there is no node n G C' such that term(n) = t. 
In this form, a value is uncompromised if the penetrator cannot extract it in 
explicit form without further cooperation of regular strands. When stated in 
this form, the assertion that a value is uncompromised is invariant under bundle 
equivalences. 

4.2 Redundancies 

Some portions of the penetrator behavior in a bundle may be redundant in the 
sense that they may be excised locally. Removing them leads to a simpler yet 
equivalent bundle. We identify here two kinds of redundancy. First are cased 
where the penetrator encrypts a value with a key K, and then decrypts with 
the corresponding decryption key K~^. This is illustrated in the upper portion 
of Figure 13, and may be eliminated by omitting nodes and adding the dotted 
arrow shown in the lower portion. Something very similar arises if the penetrator 
concatenates two values and then promptly separates the concatenated unit 
into its two immediate subterms. Since these operations introduce no cycles, 
the resulting graph is a bundle. They remove only penetrator nodes, so the 
new bundle is equivalent to the original one. Finally, since each bundle is finite, 
the process of removing redundancies must finally terminate with an equivalent 
bundle containing no redundancies. 

As a consequence, we may assume that the penetrator’s behavior always 
follows a specific pattern: 

First take messages apart; 
then put messages together; 

finally deliver the resulting messages to a regular principal. 

In order to formalize this pattern, we introduce the notion of a path. 
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Fig. 13. E-D redundancies, and how to eliminate them 



4.3 Paths 

m n means that m, n are nodes on the same strand with n occuring after m 
(Definition 2, Clause 4). The notation m i — > n means: 

Either m =^"'" n with term(m) negative and term(n) positive, 
or else m ^ n. 

A path p through C is any finite sequence of nodes and edges ni i — > U 2 ' — *■ 
• • • I — > rifc. We refer to the ith node of the path p as pi. The length of p will 
be \p\, and we will write i{p) to mean p|p|, i.e. the last node in p. A penetrator 
path is one in which all nodes other than possibly the first or the last node are 
penetrator nodes. As an example of a penetrator path, in which the first and last 
nodes are in fact regular, consider again the partial bundle shown in Figure 14. 
The path tt = 

7Ti ^ 7T2 7T3 ^ 7T4 TT^ — > TTg 

is a path that traverses penetrator nodes, connecting A’s first transmission 
^NaA^Kp to B's first reception t^NaA^Kp- Iii contrast to tt, the path 4> = 

i>l '02 TTS ^ TTe 

starts on a penetrator node and ends on a regular node. Observe that by our 
conventions, 03 and 04 are well-defined (and equal to tts and ttq respectively). 
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Fig. 14. Penetrator strands for Lowe’s attack on Needham-Schroeder 



4.4 Constructive and Destructive Edges, Normal Bundles 

Definition 10. A -edge is constructive if it is part of a E or C strand. It is 
destructive if it is part of a D or if it is part of a S strand. 

A penetrator node n is initial if it is a K or M node. 

Any penetrator path that begins at a regular node contains only constructive 
and destructive =^'*'-edges, because initial nodes can occur only at the beginning 
of a path. 

Proposition 2 In a bundle, a constructive edge immediately followed by a de- 
structive edge has one of the following two forms: 

1. Part of a Eh.x immediately followed by part of a Dh^K strand for some h, K . 

2. Part of a Cg^h immediately followed by part of a Sg^h strand for some g, h. 

This result requires the freeness of the message algebra. 

Proposition 3 (Penetrator Normal Form Lemma) If the bundle C has 
no redundancies of type C-S and E-D, then for any penetrator path of C, every 
destructive edge precedes every constructive edge. 

Every bundle is equivalent to a bundle with no redundancies of type C-S and 
E-D. 

We call a bundle normal if it has no redundancies of type C-S and E-D, by 
analogy with Prawitz’s normal deductions [42]. Many others have noted related 
properties, including [7,40,20]. 

We may also assume another property of the bundle C. 

Definition 11. C is directed if for every node n G C, there is a regular node 
m € C such that n w. 
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Every bundle C is equivalent to some directed bundle C . Define the graph C' 
to contain those nodes n of C such that n -<c m for some regular node to; the 
arrows of C' are those arrows of C that connect nodes in C'. C' is easily seen to be 
a bundle by enumerating the clauses in Definition 3. Moreover, C' is equivalent 
to C, just by the refiexiveness of 

4.5 Rising and Falling Paths 

We will call a path p rising if term(pi) C term(pi_|_i) whenever 1 < i and 
* + 1 < Ip I- This means that each term is a subterm of the next, and ultimately 
the first is a subterm of the last. Moving in the other direction, we will call 
a path p falling if term(pi_|_i) C term(pi) whenever 1 <i and i + 1 < |p|. In this 
case, each term includes the next, so that the last is a subterm of the first. 

A destructive =>-edge may not be part of a falling path, because the path 
may traverse the key edge of a D-strand, as shown in left diagram of Figure 15. 
K~^ will typically have no relation to h. As we see in the right side, a E-strand 
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Fig. 15. Key edges into D and E-strands 



is similar, since with our definitions, K unless by chance K \Z h. 

However, as long as a path p does not traverse a key edge, it will be falling while 
traversing destructive penetrator strands and rising while traversing constructive 
penetrator strands. 

Falling Paths, Rising Paths, and Subterms Falling paths have a property we 
need to explain; rising paths have a dual property. As we follow a falling path, 
we traverse a number of S-strands, which select a subterm from a concatenation, 
and a number of D-strands which select a plaintext from an encryption. If the 
encryption is of the form {|/i|}if, then the key used on this D-strand is K~^. 

Suppose that p is a falling path and A is a set of keys, and suppose that 
p traverses a D-strand only when the key used is of the form K~^ for some 
AT S A. So the ciphertext is always of the form with AT € A. That means 

that the term pi at the start of p is of the form 



••J---term(£(p))---B-if ••• 
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in the sense that it can be constructed from term(£(p)) by concatenating (with 
anything) and encrypting using only keys K £ This is what in Definition 7 
we wrote term(£(p)) iZa pi. 

The case of a rising path is similar except that we may omit the inverses. 
Suppose that p is a rising path and is a set of keys, and suppose that p traverses 
an E-strand only when the key used is some K G Then pi term(£(p)). 

4.6 A Catalog of Penetrator Paths 

This suggests that we separate penetrator activity into paths which do not tra- 
verse key edges; we end a path p at the node before it traverses a key edge. In 
this case, term(£(p)) = K for some key K. The ciphertext is of the form 
if we stopped before an E-strand, and of the form if we stopped before 

a D-strand. 

In cataloging penetrator paths, we may assume that the bundle is normal, 
since otherwise there is an equivalent bundle that is. We may also assume that 
the bundle is directed. From this, we may infer that a penetrator path terminates 
only when it reaches either a key edge or a regular node. 

Thus, the purpose of a penetrator path is always either: 

— To make a key available for a D or E-strand, or 

— To construct some message to deliver to a regular node. 

The first type of path terminates before a key edge, and the second terminates 
at a regular node. 

In our catalog of paths p that never traverse a key edge, we will also dis- 
tinguish possibilities depending whether p begins on a penetrator node or on 
a regular node. 

1. p begins on a penetrator node and ends before a key edge. Then term(^(p)) = 
K, and since pi is an initial penetrator node, it must be a K node with |p| = 1. 

2. p begins on a regular node and ends before a key edge. So term(£(p)) = K. 
Because p never traverses a key edge and ends with an atomic term, p is 
falling. So K \Z term(pi). In other words, the penetrator has extracted a key 
from a message sent by a regular principal. By our remark at the beginning 
of Section 4.6, if every occurrence of K in term(pi) is encrypted using some 
other key Ki, then is a key edge joining p at some D-strand. There 
must be an earlier path p' furnishing this key . 

3. p begins on a penetrator node and ends at a regular node. Then pi is either 
a K node or a M node, and in either case term(pi) is atomic. Therefore p is 
a rising path and term(pi) C term(£(p)). In this path, the penetrator makes 
up a value, and after possibly combining it with other ingredients, delivers 
it to a regular participant at i{p). 

4. p begins at a positive regular node and ends at a negative regular node. In 
this case, p consists of a falling portion followed by a rising portion, either 
(or both) of which can be trivial in the sense that it consists of a single node 
and no arrows. 
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Thus, there is a falling path q ending at a positive node ^( 9 ), and a rising 
path q' beginning at a negative node gji where term(£(g)) = term(g5^). We 
call this common term the path bridge term of p, writing it as pbt(p). The 
whole path p is of the form q ^ q' . 

We know that pbt(p) IZ term(pi), and pbt(p) Z term(£(p)). So the effect of 
the whole path p is to extract the term pbt(p) via the falling part q, and 
compose it with other ingredients in the rising part q' , delivering the result 
to a regular participant. 

This is a complete listing of what the penetrator can achieve by means of any 

path. 



4.7 New Components and Efficient Bundles 



According to Definition 7, a component of t is a subterm to such that to is either 
an atom or an encryption, and such that there are no encryptions hiding to in t. 
Thus, given a term t, we generate the set of its components by repeatedly sep- 
arating concatenations, stopping whenever we reach an atom or an encryption. 
Components are important in cryptographic protocols, because the penetrator 
can always undo concatenations and redo them in whatever form is desired. 
Only the cryptographic work required to change components can provide au- 
thentication or confidentiality. We write to Z t to mean that to is a component 
of t. 



A term to is a new component of a node n if 
n it is not the case that 



to Z term(n), and whenever 



to 



Z term(m). That is, it should not have been 
a component of an earlier node on the same strand. We are interested in the 
new components of a node, because they summarize what cryptographic work 
has been done at that point on the strand. 

To simplify reasoning about bundles, it is convenient to assume that when a 
penetrator gets a component from the regular participants, he gets it from the 
earliest point possible. We call such a bundle efficient. 



Definition 12. A bundle is efficient if and only if, for every node m and nega- 
tive penetrator node n, if every component of n is a component of m, then there 
is no regular node m! such that m ^ m! ^ n. 



We call a bundle of this kind efficient because the penetrator does the most with 
what he has rather than making use of additional regular nodes. 

All of the bundles we have shown in earlier figures are efficient. Whenever 
the penetrator node handles a term, there is no earlier node that has all the 
same components, and a regular node has been traversed in between. However, 
in the case of the nonsensical variant of the Needham-Schroeder protocol shown 
in Figure 16, the edge marked would need to be removed, and replaced with 
the dashed diagonal. The negative penetrator node n must not receive its term 
from the third initiator node, when it can be obtained directly from the first 
initiator node. 

Every bundle C may be replaced by an equivalent efficient bundle C , and 
C will be normal or directed assuming that C was. 
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Fig. 16. An inefficient bundle for a fictitious protocol 



4.8 Penetrable Keys 



We may use the ideas we have developed to give an easy way to determine 
whether the secrecy of a key is preserved by a protocol. Let us suppose that C is 
a bundle in which some key K is disclosed, meaning that there exists a node 
n G C such that K IZ term(n). We may assume that C is normal, directed. 



and efficient. By the bundle induction principle, we may assume that n has been 
chosen minimal in the ordering with component K. We want to determine 
when a key is penetrable. 

There are only three cases: 



— n may be a K node, in which case K € Kp; 

^ n may be a regular node, in which case (by minimality), K is a new compo- 
nent of n; 

— n lies on a penetrator path p at node pi with 1 < i. We may assume that 
p traverses no key edges. 



In the last case, the path (pi, . . . ,pi) is falling, as it ends with an atomic value, 
so Pi is a regular node. We know from Section 4.5 that K \Zfi term(pi), where 
A contains Ki whenever was used in a D-strand along p. 

So a collection of previously penetrable keys, namely the for Ki € .^, 

Z term(pi). By the efficiency 



to 



suffice to extract K from some component 
of C, to is a new component of the regular node pi . 

Letting .^ = 0, this also covers the second case. Therefore, for every penetra- 
ble key K, either: 



1. K G Kp, or 

2. There is a regular node m G C and a new component to of m such that 
K Zj? to, where for every AT G A, ATf ^ is already penetrable. 

So every key that the penetrator learns, he either starts off knowing in K-p, or 
else some regular participant puts K into a new component, where it is protected 
only by keys that the penetrator can already learn to undo. In this construction. 
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we are primarily interested in paths of type 2 in our list of possible types of 
penetrator path in Section 4.6. 

We may therefore define P(C) to be the smallest set of keys such that Kp C 
P(C) and closed under Clause 2 as just given. We have just proved that \i K = 
term(n) for any n G C, then K G P(C). 

Why is this useful? Because we can define a set of safe keys such that it 
is very easy to see when a key is safe, and the safe keys are disjoint from the 
penetrable keys. 



4.9 Safe Keys 



Let So(C) be the set of keys K such that: 



— K ^ Kp, and 

— for every positive regular node n G C and every new component 
term(n), K 



to 



□ 



These keys are patently safe. No regular principal will ever utter them in a com- 
ponent, unless given that component earlier. So, no one is ever the first to spill 
the beans. 

Let Si+i(C) be the set of keys K such that: 



G C and every new component to 



K ^ Kp, and 

for every positive regular node n 
term(n), every occurrence of K in to lies within an encryption using some 
key I<o where G Si(C): 



... ... K ■■■ ■■■ 

These keys are derivatively safe, since they can never be penetrated unless the 
penetrator gets which is already known to be safe. 

In practice, protocol secrecy goals frequently amount to showing that cer- 
tain keys are in either Sq or Si. Larger values of i seem rarely to occur in these 
protocols. Showing that a private key or a long-term symmetric key is in So typ- 
ically reduces to checking that it is assumed not to be in Kp, because protocols 
generally avoid emitting terms containing these keys. 

For instance, in the Needham-Schroeder protocol, if n is a regular node, then 
K [Zi term(n). Hence, So = K \ K-p, which says that any key not initially known 
to the penetrator is permanently safe. 

Many protocols expect session keys to be generated by a key server, which 
sends them encrypted in the long-term keys of two principals, and no principal 
ever re-encrypts a session key under a new key. In a particular session, a session 
key K may be sent encrypted with long-term keys not in K-p (or, if they are 
asymmetric, their inverses are not in Kp). If the server never re-sends the same 
session key K in a different session, then K G Si . This method is an easy way 
to establish secrecy. 
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5 Proving Authentication 

We focus now on protocols in which a regular participant authenticates its peer 
by sending a fresh value a (typically a nonce N), expecting to receive it back 
in a cryptographically altered form. If only the intended peer can perform the 
right cryptographic operation, then this pattern will authenticate the peer. The 
treatment of authentication tests in this section differs from that in [16], and is 
indebted to [41]. 

Consider some arbitrary bundle C. 



5.1 The Outgoing Authentication Test 

Let us say that no =^“'" ni is an outgoing test edge for a if 



a originates uniquely on uq] 

There is only one component to = 



m 



K 



to [Zl term(ni) but a C term(ni); and 
A-i 4 P. 



IZ term (no) such that a n to] 



Consider the set S = {m G C: a \Z term(m) A to 4 term(m)}. S is non-empty, 
because ni G S. So by the bundle induction principle, S has minimal mem- 
bers mi. 

We claim that no such mi is a penetrator node. Clearly such an mi is pos- 
itive, since if it were negative, it must receive its message from another node 
with the same property. If mi is an initial penetrator node, this contradicts the 
assumption that a originates uniquely at no- Thus, if it is a penetrator node at 
all, mi lies on an edge mo =>“*' mi where to Z term(mo) but to 4 term(mi). 
Since to = {]h[|-i<-, mo mi lies on a D-strand, with key edge K~^. But this 
contradicts the assumption that K~^ 4 P- Therefore, every minimal member 
of S is regular. 

Let us call a regular edge mo =^“'" mi a transforming edge for no =^~'' ni 
if to Z term(mo) and mi is a minimal member of S. 

The outgoing test authentication principle states that if C contains an out- 
going test edge, then it also contains a (regular) transforming edge for it. 

The meaning of this assertion is illustrated in Figure 17. The two bulleted 
nodes in the figure represent mo and mi. 



The Outgoing Test in Needham- Schroeder We may illustrate the outgoing au- 
thentication tests by Needham-Schroeder (see Figure 4). Assume that C is a bun- 
dle, and the C-height of Sr G NSResp[A, i?, A^, A;,] is 3, which means that all 
three nodes of Sr belong to C. Assume that 4 ^v- Finally, assume that A{, 
originates uniquely, and A{, yf A^ (which together mean that A{, originates 
uniquely at the second node of Sr). 

Hence, the edge from the seocnd node of s^ to its third node is an outgoing 
test edge for Af,. By the Outgoing Authentication Test principle, there exist 
regular nodes mo, mi G C such that mo =^~'' mi is a transforming edge for it. So 
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Fig. 17. Authentication provided by an outgoing test 



^Na Nb^KA C (mo). The only negative regular node containing a subterm of this 
form is the second node of an initiator strand Si for Si G NSInit[A, i?', TV^, TVf,] 
and some responder B' . Thus, the transforming edge mg mi must be the 
edge from the second node of Si to its third node, and Si has C-height 3. 

Unfortunately, we have not proved that Si G NSInit[A, i?, iVa, fV^] for the 
expected responder B, rather than some other responder B' . And Figure 5 is a 
counterexample in which B' = P ^ B. Hence we have uncovered a limitation in 
the authentication achieved by Needham-Schroeder, first noted by Lowe [26,27], 
which led Lowe to amend the protocol to contain the responder’s name B in the 
second message ^Na Ni, B^Ka- 

The Outgoing Test in Needham-Schroeder- Lowe Consider now the corrected 
Needham-Schroeder-Lowe protocol as shown in Figure 12. As before, assume 
that C is a bundle, and the C-height of Sr € NSResp[A, H, A”a, A”},] is 3. Assume 
again that ^ Kp; that Nb originates uniquely; and that Nb yf Na- 

We again infer that there exist regular nodes mo, mi gC such that mg =^"*" mi 
is a transforming edge for it. So {] A„ Nb B^Ka (”^o)- The only negative regular 

node containing a subterm of this form is the second node of an initiator strand Si 
for Si G NSInit[A, H, Aq, Af,]. Hence, the desired Si has C-height 3. 

5.2 The Incoming Authentication Test 

Let us say that no ni is an incoming test edge for a if 

— a originates uniquely on ng, and ti = [Zl term(no); 

— a C ti, and ti C term(ni); and 

— A ^ P. 

We call a regular edge mo =!>“'' mi a transforming edge for ng ni if mg 
contains a as a subterm and mi is a minimal node such that fi IZ term(mi). 

As before, only a regular edge can have this property. This assertion is il- 
lustrated in Figure 18 using the same conventions as in Figure 17. Carlsen’s 
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*a C term(no) 




Fig. 18. Authentication provided by an incoming test 



protocol (see Figure 10) is designed around incoming authentication tests. So is 
the Neuman-Stubblebine protocol, as we will illustrate in Section 5.4. 



5.3 The Unsolicited Test 



One other authentication test is important especially in the case of a key server, 

K C term(n) 



but in some other instances too. This is the unsolicited test. If 



and K ^ P, then we may infer that there is a node m such that: 



— m is regular; 

— H/iOif originates at m. 

This is valid because certainly originates at some node m, and m cannot 

be a penetrator node: If it were, it would be the positive node of a D-strand. And 
then the preceding key node would have the term AT, contrary to the assumption 

K ^P. 



5.4 Neuman-Stubblebine 

The Neuman-Stubblebine protocol [38] contains two sub-protocols. We will call 
the first sub-protocol the authentication protocol and the second sub-protocol 
the re-authentication protocol. In the authentication sub-protocol, a key dis- 
tribution center generates a session key for an initiator (a network client) and 
a responder (a network server); the message exchange is shown in Figure 19. 
This session key is embedded in encrypted form in a re-usable ticket of the form 
{] A K T\kb ■ III Ills re-authentication protocol the client presents the same ticket 
again to the network server to use the same key for another session. The value T 
is an expiration date, after which the network server should no longer accept the 
ticket, although we will not bother to model this aspect of the behavior. 

We consider the authentication protocol alone first. Strands of the form 
shown in the columns labelled A, B, and S in Figure 19 will be called 

- lmt[A,B,Na,Nb,tb,K,H], 

- Resp[A, B, Na, Nb,tb, K], and 

- Serv[A, B, Na, NbAb, K], 
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Fig. 19. Neuman-Stubblebine part I (Authentication) 



respectively. 

We define LT to be the set of long-term keys, i.e. the range of the injective 
function Ka for A G Tname- All long-terms keys are symmetrical: K G VJ 
implies K = K~^ . 

We likewise assume that the key server generates keys in a reasonable way, 
meaning that that Serv[**, AT] n C = 0 unless: 

- K ^ K-p; 

- K = AT-i; 

- K is uniquely originating in C; 

- K ^11. 

Because of the unique origination assumption, it follows that the cardinality 
|Serv[**, AT] H C| < 1 for every AT. We say that C has a reasonable server when 
these conditions are met. 

The overall strategy for showing the responder’s guarantee, assuming given 
a bundle C such that C has a reasonable server and C contains a strand Sr G 
Resp[A, B , Na, K] with Ka,Kb ^ Kp, is the following: 

1. Observe that LT C Sq U Kp, as the protocol never transmits a long-term 
key. For any key AT', if Serv[A, i?, *,*,*, AT'] ^ 0, then K' is transmitted 
protected by Ka and A'p, but it will never be transmitted with any different 
protection (with a reasonable key server). Since Ka,Kb G Sq, AT' G Si 
whenever Serv[A, B, *,*,*, AT'] ^ 0. 

2. ^AKtb'^KB is an unsolicited test, originating on a regular strand. This can 
only be a server strand Sg G Serv[A, B, *, *, ti,, AT]. Therefore, K G Si. 

3. M 2 M 4 is an incoming test for Aj, in Hence, there is a regular 

transforming edge producing {|W|}if- This can lie only on the second and 
third nodes of an initiator strand Si G Init[A', H', TV' , W, AT, *]. 
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4. The first and second nodes of Si form an incoming test for N^. Therefore, 

there is a regular transforming edge producing ^B' This can 

only be € Serv[^', B', *, K]. 

5. By the assumption that C has a reasonable key server, K is uniquely orig- 
inating in C. Therefore, s'^ = Sg, and A' = A, B' = B, = tb- Thus, 
Sj € Init[A, B, *, Nb, h, K, *]. 

The initiator’s guarantee is simpler to establish. The edge Mi M 3 on an 
initiator strand is an incoming test for Na in ^B Na K tb'^KA ■ shows there is a 
server strand Sg € Serv[^, B, *, tb, 71']. The first node of Sg is an unsolicited 
test, showing the existence of a responder strand Sr G Resp[^, B, Na, *, h, *]. 

In the re-authentication sub-protocol, the key distribution center no longer 
needs to be involved; the initiator again presents the same ticket to the responder, 
as shown in Figure 20. In this diagram, the first arrow inbound to the initiator 



A B 

• ► • 

f ^ NUKU f 

f mu , f 

Fig. 20. Neuman-Stubblebine, part II (Re-authentication) 



strand does not represent a real message; it represents the state stored in the 
initiator that preserves the ticket for later re-use. 

In the presence of this additional sub-protocol, step 3 in the responder’s guar- 
antee can no longer be completed. There must certainly still be a transforming 
edge producing {] but this edge may lie either on an initiator strand for 

Part I of the protocol, or on (conceivably) either type of strand for Part II. 
By contrast, the initiator’s guarantee for Part I is unaffected, because we have 
not added any strand with a transforming edge producing a term of the form 
^BNaKtb^KA- 

This example illustrates the need for a systematic way to understand protocol 
mixing, as for instance the mixing of part I and part II of Neuman-Stubblebine. 
We undertake that task in the next section. 

6 Protocol Independence via Disjoint Encryption 

Whether a cryptographic protocol achieves a security goal depends on what 
cannot happen. To authenticate a regular principal engaging in a protocol run, we 
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must observe a pattern of messages that can only be constructed by that principal 
in that run, regardless of how the penetrator combines his own actions with those 
of principals engaging in other runs, as codified in the Dolev-Yao model [9]. 
When several cryptographic protocols are combined, the penetrator has new 
opportunities to obtain the messages which ought to authenticate principals to 
their peers. The penetrator has more unintended services to draw on. 

Indeed, because protocol mixing has shown itself to be a significant cause of 
protocol failure, and makes protocol analysis more difficult [6,10,23,35,46,48], it 
has been identified [36] as a key problem in applying formal methods to crypto- 
graphic protocols. 

Moreover, in practice, different protocols using cryptography are usually com- 
bined. A key distribution protocol is useful only if the session key it delivers is 
used for encryption. That later use may involve constructing messages similar 
to messages used in the key distribution protocol itself. Does this make replay 
attacks possible? Does the use of a key undermine the guarantees provided by 
the protocol distributing that key? Or conversely, can the penetrator manipulate 
messages from the key distribution protocol to spoof the later use of the key? 

There are other reasons why protocol mixture is prevalent. Many recent pro- 
tocols have large numbers of different options, and therefore have large numbers 
of different sub-protocols [33,18,8,35]. Each of these protocols may be easy to 
analyze on its own. But the same principal is required to be able to engage in 
any sub-protocol. Can the penetrator manipulate this willingness for his own 
purposes? 

When protocols are mixed together, and we want to appraise whether the 
security of one is affected by the others, we will refer to the protocol under study 
as the primary protocol. We will refer to the others as secondary protocols. 

6.1 Avoiding Conflict 

Common sense suggests a rule of thumb when protocols are to be mixed together. 
This rule is that if the primary protocol uses a particular form of encrypted 
message as a test to authenticate a peer [14], then the secondary protocols should 
not construct a message of that form. If the primary protocol uses a particular 
form of encrypted component to protect some private value, then the secondary 
protocol should not receive messages of that form and retransmit their contents 
in other (potentially less secure) forms. Putting these two ideas together, the 
sets of encrypted messages that the different protocols manipulate should be 
disjoint. 

In the case of Neuman-Stubblebine, for instance, the ticket {] A K T^Kb origi- 
nates on the primary protocol; it is stored by the initiator for use in the secondary 
protocol; and it is then manipulated and transformed by the responder in the 
secondary protocol. This violates the disjointness we would like to maintain. 

One way to arrange for disjoint encryption is to give each protocol some dis- 
tinguishing value, such as a number; that number may then be included as part 
of each plaintext before encipherment. Then no principal can mistake a value as 
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belonging to the wrong protocol; an encrypted value bearing a different proto- 
col’s number must not be transformed. Another way to achieve disjoint encryp- 
tion is to ensure that different protocols never use the same key, although this 
may be expensive or difficult to arrange. Although the Abadi-Needham paper 
on prudent engineering practice for cryptographic protocols [1] does not discuss 
mixing different protocols, this rule — to try to achieve disjoint encryption — is in 
the same spirit as those it proposes. 

In this section, we will prove that, properly formalized, it suffices. If two 
protocols have disjoint encryption, then the first protocol is independent of the 
second. By this we mean that if the primary protocol achieves a security goal 
(whether an authentication goal or a secrecy goal as defined in Sections 3.12- 
3.13) when the protocol is executed in isolation, then it still achieves the same 
security goal when executed in combination with the secondary protocol. 

One of the advantages of our approach is that the result works for all secrecy 
and authentication goals; in this it continues a trend visible from several recent 
papers [31,21,45,44,19]. We have an additional reason for including this material 
here: It is a good example of the power of the machinery of paths and well- 
behaved bundles developed in Section 4. 

6.2 Multiprotocol Strand Spaces 

To represent multiple protocols [46] , we select some regular strands as being runs 
of the primary protocol; we call these strands primary strands. 

Definition 13. A multiprotocol strand space is a strand space (A, tr) together 
with a distinguished subset of the regular strands Si G E \ Vs called the set of 
primary strands. 

S 2 denotes the set of all other regular strands, called secondary strands. A node 
is primary or secondary if the strand it lies on is. From the point of view of 
a particular analysis, the secondary strands represent runs of other protocols, 
different from the primary one under analysis. 

The notion of equivalence needed for our purposes in this section concentrates 
on primary nodes. 

Definition 14. Two bundles C,C' in the multiprotocol strand space {E,tr, Si) 
are equivalent if and only if 

1. they have the same primary nodes, meaning C G Ei = C' G Ei; 

2. for all a, a originates uniquely and on a primary node in C if and only if 
a originates uniquely and on a primary node in C ; 

3. for all a, a is non- originating in C ijf a is non-originating in C . 

Since this is a more liberal notion of equivalence (it requires fewer nodes and 
unique origination facts to be unchanged) , any existence assertion about equiv- 
alent bundles from Section 4 remains true in the present context. 

We will also jettison the strand space parameter Kp for our current purposes, 
and express our assumptions about safe keys purely in terms of non-origination. 
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For our present purposes, this has the advantage of not distinguishing whether 
a key is disclosed through a K-strand or through a secondary strand. The effect 
for us is now the same. 



6.3 Linking Paths 

From Section 4, we also know that every bundle C is equivalent to a directed 
bundle C (Definition 11), and this remains true with our new definition of equiv- 
alent, assuming that in the definition of directed bundles we make the same 
substitution of “primary” for “regular:” 

Definition 15. C is directed if for every node n € C, there is a primary node 
m G C n Si such that n -<c "m. 

Suppose we can show that given any bundle C involving both protocols, we 
can find an equivalent bundle in which no path leads from a secondary node 
to a primary node. Then there is also an equivalent C in which there are no 
secondary nodes at all. Therefore, if C is a counterexample to some authentication 
goal, C is a counterexample in which the secondary protocol does not occur at 
all. This will establish protocol independence for authentication goals. 

Let us say that a penetrator path p is an inbound linking path if po G S 2 
and i{p) G Si. We thus take the point of view of the primary path, and regard 
p as linking the secondary node to a primary node. One of the crucial steps in 
showing protocol independence is showing that we can unlink inbound linking 
paths. 

A penetrator path p is an outbound linking path if pq G Si and i{p) G S 2 - We 
need not unlink these, but we need to ensure that they do not deliver terms to 
the secondary protocol from which the secondary protocol will extract a secret. 

6.4 Bridges 

If C is a normal bundle and p is a penetrator path through C, then all destructive 
edges precede constructive edges in p. The edge that separates the destructive 
portion of a path from the constructive portion is of special interest. We call it 
a bridge. 

Definition 16. A bridge in a bundle C is a message transmission edge m ^ n 
embedded in a subgraph of one the types shown in Figure 21. 

Ifm—fnisa bridge, then its bridge term is term(rn), which equals term(n). 
A bridge is simple iff its bridge term is simple, that is, is not of the form g h. 

Any edge between regular nodes is an external bridge. The source to of a bridge 
m n is never on a constructive penetrator strand, and the target n is never 
on a destructive penetrator strand. 

A term is simple if it is an atom or an encryption, not a concatenation (see 
Definition 7 in Section 3.14). 
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Fig. 21. Four types of bridge: internal, entry, exit, and external bridges 

Proposition 4 Suppose that C is a normal bundle, and p is any penetrator path 
in C. Then p traverses exactly one bridge. 

Any bundle C can be replaced by an equivalent bundle C in which the bridge 
term for every path is simple. Moreover if C is normal or efficient, so is C . 

The proof of the second assertion consists of adding S-strands to separate any 
concatenated bridge term g h and C-strands to reconstruct g h after the bridges 
of the two new sub-paths. 



Since every path p has a unique bridge, we can write pbt(p) for the bridge term 
occurring on the bridge. 

If a path includes penetrator nodes and regular nodes, then it never traverses 
the same component before and after a regular node: 

Proposition 5 Suppose that C is normal, efficient, and has simple bridges, 
and p is a path through C that traverses no key edges. If i < j < k, pj is 
a negative regular node, andpi,pk are penetrator nodes with simple terms, then 
term{pi) term{pk). 



gh 



o 
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Suppose moreover that pk is the first penetrator node after pj such thatpk has 
a simple term. Then pj =>■*■ Pj+i produces a new component 
and term{pk) = to- 

The result follows routinely from efficiency. 

6.5 Disjoint Encryption 

The simplest way to state the disjoint encryption assumption would be to require 
that the two protocols not use the same ciphertext as a part of any message. 
That would mean that if ni € Si and U2 G S2, and if {|h|}i<- C term(ni), then 
{|h|}K term(n2). 

However, this simple version is unnecessarily restrictive. The secondary pro- 
tocol would be unable to accept public-key certificates generated in the primary 
protocol, which is intuitively harmless because the contents are public in any 
case. The secondary protocol would also be unable to re-use symmetric-key tick- 
ets such as those generated by the Kerberos Key Distribution Center [24,38]. 
These are also intuitively harmless, so long as the secondary protocol does not 
extract private values from within them, or repackage their private contents, 
potentially insecurely. Hence, we allow these harmless exceptions to the require- 
ment that no encrypted term be used by both protocols. 

Definition 17. is a shared encryption if there exist n\ S S\ andu2 € S2 

such that {|h[}-if IZ termini) and {|h[}-if Z termin2). It is an outbound shared 
encryption if this holds with ni positive and ri2 negative. It is an inbound shared 
encryption if this holds with ni negative and U2 positive. 

We want to restrict but not prohibit shared encryptions, and we will do so in 
slightly different ways for inbound and outbound shared encryptions. 

Definition 18. (Disjoint Outbound Encryption) S has disjoint outbound 
encryption if and only if, for every outbound shared encryption {|h[}-x, for every 
atom a Z and for every U2 =^~'’ n'2 G S2, 

if U2 is negative and {|h[}-if Z ter?n(n2), 

and n'2 is positive and to is a new component of n'2, 

then a if to. 

That is, no secondary strand manipulates a into a new component. 

This definition has the important property that values originating uniquely 
on primary nodes cannot “zigzag” to a secondary node, before being disclosed 
to the penetrator. 

Proposition 6 (No Zigzags) Let S have disjoint outbound encryption, and 
let C be a normal, efficient bundle with simple bridges in S. Suppose p is a path 
such that term{i{p)) = a (where a S K U t;, a Z termfpi) for all 1 < i < \p\, 
and Pk G S2. Then pj f Si for any j < k. 



to Z term{pj+i). 



256 



Joshua D. Guttman 



Proof. Suppose otherwise. We may assume that j, k are chosen so that j is the 
largest index such that pj G and there is some later pk G S2, and k is the 
smallest value > j such that pk G ^2 ■ So the path p = pj 1 — > • • • 1 — > pk is a 
penetrator path. 

If p traverses a key edge (see Section 4.6) at pi — > Pi+i, then term(pi) = a is 
a key. Therefore Pi ^ Pk ^ ^(p)j contradicting efficiency. 

Therefore p begins at a positive regular (primary) node, ends at a negative 
regular (secondary) node, and never traverses a key edge. It is of type 4 in the 
catalog of Section 4.6. Therefore it has a bridge term pbt(p) such that pbt(p) C 
term(pj) and pbt(p) Cl term(pfe). Since a \Z pbt(p), either a is itself a component 
of pbt(p), or else a C 



m 



K 



C pbt(p). If a is a component of pbt(p), then we 
have a contradiction to efficiency as before. 

Otherwise, is an outbound shared encryption. By Proposition 5, pk =^"'’ 

Pk+i produces a new component to, and a IZ But this contradicts the defini- 
tion of outbound disjoint encryption. □ 

As a consequence, we may infer that there is never a failure of secrecy where 
any secondary node touches the secret value. 

The condition on inbound shared encryptions is that they should never occur 
in new components created on secondary nodes. 

Definition 19. (Disjoint Encryption) E has disjoint inbound encryption 
if, for every inhound shared encryption {|/i|}ic and U2 =^“'' G E 2 , if to 
term{n' 2 ) is a new component, then to- 

E has disjoint encryption if it has both disjoint inbound encryption and dis- 
joint outbound encryption. 



6.6 The Protocol Independence Theorem 

Definition 20. Ei is independent of E 2 if for every bundle C in E, there is 
a bundle C in E that is equivalent to C such that C is disjoint from E 2 - 

Proposition 7 (Protocol Independence) If E has disjoint encryption, then 
El is independent of E 2 - 

Proof. We may assume that C is normal, efficient, and has simple bridges. We 
want to show that we can remove any inbound linking paths in C. 

Let p be an inbound linking path. Suppose first that p traverses an atomic 
value a G T U K. This may either be the key edge into a D or E strand, or it 
may be the bridge of p. In any case, let a be the first atomic value on p. By 
Proposition 6, a does not originate uniquely on a primary node. Therefore, there 
is an equivalent bundle C in which a is produced by an initial penetrator strand 
(a K-strand or a M-strand) . 

Suppose next that p never traverses an atomic value. Then in particular it 
never traverses a key edge into a D or E strand. Thus, the path bridge term 
pbt(p) Z term(pi) and pbt(p) Z term(£(p)). Since pbt(p) is not atomic but it 
is simple, it is of the form -{J/iOx- Therefore, by disjoint inbound encryption, it 
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does not occur in a new component of p\. But by Proposition 5, this contradicts 
efficiency. 

Therefore we may remove any inbound linking path p in a normal, efficient 
bundle with simple bridges. It follows that there is a C' equivalent to C such that 

c' n t '2 = 0. □ 

An easy consequence of this theorem shows that if the primary and secondary 
protocols share no keys whatever, then we have independence. 

Corollary 1 For i = 1 and 2, let be the set of K such that K C term{n) for 
any n G Ei or C termfn) for any h and any n G Ei. 

If n ^2 = 0, then El is independent of E 2 - 

If Ai and E 2 involve the activity of different principals, and the keys for the 
protocols are chosen in an unpredictable way from a large set, then the keys 
they use will in practice never overlap. Therefore, E\ is independent of E 2 - The 
same holds when the same principals may participate in both protocols, but they 
choose keys independently for each protocol. 

Similarly, suppose each ciphertext created in E\ or E 2 contains a distinguish- 
ing values such as different protocol numbers. If E\ never accepts a ciphertext 
containing A 2 ’s value, then we have disjoint inbound encryption. If E 2 never ex- 
tracts a subterm from a ciphertext containing Ai’s value, then we have disjoint 
outbound encryption. Together, they suffice for protocol independence. 

6.7 An Application of Protocol Independence 

Let us return to the Neuman-Stubblebine protocol, as described in Section 5.4 
and summarized in Figures 19 and 20. 

We regard the re-authentication protocol as the secondary protocol; the pres- 
ence of the re-authentication protocol should not undermine any security guar- 
antee offered by the primary protocol. However, terms of the form {|fV|}if are 
constructed as new components on secondary strands, and accepted on primary 
strands. Hence the corresponding multiprotocol strand space does not have dis- 
joint inbound encryption. Indeed, the penetrator can use a session of the re- 
authentication protocol to complete a responder strand in a bundle with no 
initiator [46]. 

For this reason, we amend (see [46]) the re-authentication protocol to the 
form shown in Figure 22. To apply our independence theorem, we check that 
the corresponding strand space E has disjoint encryption. But that is trivial, 
because tickets I\AKT\kbs only common encrypted subterms of pri- 

mary and secondary nodes. The outbound property holds because no private 
subterm of a ticket is uttered in a new component of a secondary node. The in- 
bound property holds because no new component of a secondary node contains 
a ticket. 

Therefore, if C is a counterexample to some security property, we may deform 
C into an equivalent standard bundle C , in which there are no secondary nodes. 
C is still a counterexample, assuming that the security property is invariant 
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Fig. 22. Neuman-Stubblebine, part II modified (Re-authentication) 



under bundle equivalences, as authentication and secrecy properties are. Thus, 
if the primary protocol fails to meet the security goal, that is independent of 
the presence of the secondary protocol: the corrected Neuman-Stubblebine re- 
authentication protocol is entirely guiltless in this affair. 

6.8 Conclusion 

In this report, we have focused on two information security problems. One is 
the packet protection problem, where we have studied filtering routers and 
firewall-oriented security goals that they are capable of achieving. The other 
is the Dolev-Yao problem, where we have studied how to achieve authentication 
and confidentiality goals in the presence of an active penetrator. 

In both areas, we applied essentially the same method. We identified a class 
of security goals that capture important real-world security services that people 
need to achieve. We introduced simple mathematical modeling notions, such as 
directed graphs, boolean algebras, and freely generated algebras. In terms of 
this vocabulary, we were able to formalize the security goals and develop proof 
techniques and algorithms to determine what postures or protocols achieve the 
goals. 

We regard these two problems as instances of foundational work in secu- 
rity management. Although the phrase sounds prosaic, the problems it covers 
are fundamental in a world where many mechanisms and systems cooperate to 
achieve our security objectives. Knowing that they jointly achieve something 
meaningful is difficult. Yet the problems have enough structure to repay mathe- 
matical abstraction, and the abstractions tell us, systematically, how to marshal 
the mechanisms to achieve practical protection. 
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Abstract. There is great interest in applying nominal calculi — compu- 
tational formalisms that include dynamic name generation — to the prob- 
lems of programming, specifying, and verifying secure and mobile com- 
putations. These notes introduce three nominal calculi — the pi calculus, 
the spi calculus, and the ambient calculus. We describe some typical 
techniques, and survey related work. 



1 Introduction 

Programming a concurrent application is difficult. Deadlocks and race conditions 
are well known problems in multi-threaded applications on a single machine. 

Programming a concurrent application running on a distributed network is 
more difficult, as we must deal with additional problems such as partial failure of 
one or more of the host machines. Moreover, if there are untrustworthy hosts on 
the network, as on the internet, we may need to resort to cryptographic protocols 
to achieve security, and such protocols are notoriously hard to get right. 

Programming a concurrent application running on a network that includes 
mobile hosts or mobile software is still more difficult. We need to solve the com- 
munication problem of supporting reliable interaction between mobile devices or 
between mobile software agents. We need to solve the security problems induced 
by untrusted code and untrusted hosts. 

These notes introduce an approach to these problems of security and mo- 
bility based on three related calculi for concurrency, all of which stress the im- 
portance of names. We call these nominal calculi. The three calculi are tiny 
but extremely expressive languages for programming concurrent computations. 
These calculi have well defined formal semantics upon which sophisticated se- 
mantic theories have been constructed. The point of defining the calculi and 
exploring their theories is to help shed light on the difficulties of programming 
concurrent, distributed, and mobile computations. The ways in which these cal- 
culi and their theories can help include the following. We can program intricate 
computations — such as protocols for communications or security — within these 
calculi, and apply their theories directly to try to prove properties or to expose 
flaws. We can use these calculi as simple settings in which to prototype program- 
ming models — such as communication or mobility primitives — that subsequently 
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can be implemented as new libraries or language extensions in full programming 
langauges. Similarly, we can develop static checks such as type systems or flow 
analyses for these simple calculi and subsequently apply them to full languages. 

In these notes on nominal calculi, we emphasise the application of equational 
reasoning and type systems to reasoning about security and mobility. Moreover, 
we survey other work on implementations and on other formal techniques such 
as logics and flow analyses. 

Pure Names and Nominal Calculi 

In his 1989 lecture notes on naming and security in distributed systems, Need- 
ham [Nee89] stresses the usefulness of pure names for referring to distributed 
objects. Needham defines a pure name to be “nothing but a bit pattern that is an 
identifier, and is only useful for comparing for identity with other bit patterns — 
which includes looking up in tables in order to And other information” . An 
example of a pure name is the 128-bit QUID (Globally Unique Identifier) that 
uniquely identifies an interface or an implementation in the COM component 
model [Box98]. A pure name is atomic. In contrast, an impure name is one with 
some kind of recognisable structure, such as a file path or a URL containing 
a path. An impure name does more than simply name a single object. For exam- 
ple, the file name rmn/ animals /pig may imply the presence of a directory rmn 
and a subdirectory animals. 

The idea of a pure name is a useful abstraction for referring to many kinds 
of computational structures, not just distributed objects. All three formalisms 
described in these notes include an abstract set of pure names and an operator 
for local generation of fresh, unguessable names. This is what we mean when we 
say that a formalism is a nominal calculus. 

The Pi Calculus — Programming with Names 

The pi calculus [MPW92, Mil99, SWOl] is a small but extremely expressive 
programming language. It is the original example of a nominal calculus, and is 
the archetype for many others. It was originally designed to be a foundation for 
concurrent computation, in the same way as the A-calculus is a foundation for 
sequential computation. First published in the same year as Needham’s lecture 
notes, it places a still greater emphasis on pure names. The pi calculus embodies 
the view that in principle most, if not all, distributed computation may usefully 
be explained in terms of exchanges of names on named communication channels. 

Programs in the pi calculus are systems of independent, parallel processes 
that synchronise via message-passing handshakes on named channels. The chan- 
nels a process knows about determine the communication possibilities of the 
process. Channels may be restricted, so that only certain processes may commu- 
nicate on them. In this respect the pi calculus is similar to earlier process calculi 
such as CSP [Hoa85] and CCS [Mil89]. 

What sets the pi calculus apart from earlier calculi is that the scope of 
a restriction — the program text in which a channel may be used — may change 
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during computation. When a process sends a restricted name as a message to 
a process outside the scope of the restriction, the scope is said to extrude, that 
is, it enlarges to embrace the process receiving the channel. The communication 
possibilities of a process may change over time; a process may learn the names 
of new channels via scope extrusion. Thus, a channel is a transferable capability 
for communication. 

A central technical idea of these notes is to use the restriction operator and 
scope extrusion from the pi calculus as a formal model of the possession and 
communication of secrets, such as cryptographic keys. These features of the pi 
calculus and other nominal calculi are essential in our descriptions of security 
protocols. At the formal level, we can guarantee freshness absolutely by treating 
a fresh name as a bound variable, distinct from all others. At the implemen- 
tation level, there are several strategies to guarantee freshness; a common one 
in a distributed setting is to do so probabilistically by treating a fresh name as 
a random bitstring of sufficiently many bits to make collisions implausible. 

The pi calculus enjoys a broad mathematical theory — including observational 
equivalences, program logics, and type systems — that addresses the difficulty 
of programming concurrent applications. Remarkably, a wide variety of data 
structures — from bits, tuples, and lists, through to objects — and procedural 
abstractions — such as functions and methods — can all be reduced to interac- 
tions on named channels. Hence, the pi calculus is a basis for semantic accounts 
of functional, imperative, and object-oriented programming, and for the design 
of several concurrent languages [FG96, PTOO, OdeOO], as well as other applica- 
tions. In Part I of these notes, we introduce the pi calculus informally, as a simple 
programming notation for describing abstract versions of security protocols. 

The Spi Calculus — Programming with Cryptography 

Security protocols accomplish goals such as establishing the authenticity of one 
principal to another or preserving the secrecy of information during an interac- 
tion. Cryptographic protocols are security protocols implemented over a public 
network using cryptographic primitives such as encryption, digital signatures, 
and hashing. Widely-deployed examples include Kerberos and SSL. Designing 
cryptographic protocols is difficult , in part because they must work correctly even 
in the presence of an active adversary on the network, who may replay or mod- 
ify messages. Even if we rule out cryptanalysis, that is, assume perfectly secure 
cryptographic primitives, cryptographic protocols are notorious for containing 
flaws, or being brittle in the sense that apparently innocuous changes in operat- 
ing assumptions may cause failure. For example, Denning and Sacco [DS81] and 
Lowe [Low96] point out such brittleness in protocols proposed by Needham and 
Schroeder [NS78]. 

The spi calculus [AG99] is a version of the pi calculus equipped with abstract 
cryptographic primitives, in particular, with primitives for perfect encryption 
and decryption. In this nominal calculus, names represent encryption keys as 
well as communication channels. The idea is that to analyse a protocol, we 
begin by modelling it as a spi calculus program. We can then apply techniques 
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from the theory of the pi calculus such as equational reasoning or type systems 
to either show the protocol correct or identify a defect. In Part II of these notes, 
we introduce the spi calculus and explain how to apply equational reasoning to 
a series of example protocols. 



The Ambient Calculus — Programming with Mobility 

It is becoming more common for networks to include mobile devices or mobile 
software. When programming such networks, one area of difficulty is mobility: 
not so much how to move objects themselves, but how to specify which objects 
to move. This is a lesson reported by pioneers of mobile computation such as the 
designers of Telescript [Whi96] or Obliq [Car95]: in those systems, it is easy to 
move a single object or the whole running computation, but harder to specify a 
cluster of logically related objects that is to be moved. Another area of difficulty 
is security: this arises not so much from mobility itself, but from the careless or 
malicious crossing of administrative domains. 

An ambient is an abstract collection or group of running processes and objects 
that functions both as a unit of mobility — of either software and hardware — and 
as a unit of security — an administrative domain or a security perimeter. An 
ambient is a bounded place where computation happens, with an inside and 
an outside. An ambient may contain other ambients, to model related clusters 
of object or to model hierarchical administrative domains. An ambient has an 
unforgeable name. An ambient’s security rests on the controlled distribution of 
suitable credentials, or capabilities, derived from its name. A capability embodies 
the right to move a whole running ambient inside another, or the right to move 
one outside another, or the right to dissolve an ambient boundary. 

The ambient calculus [CGOOb, Car99] formalizes ambients by adopting the 
extreme position that everything is an ambient. Its purpose is to provide a formal 
model for describing mobility, and to be a prototypical programming language 
for mobile applications. Processes have a spatial structure induced by ambient 
nesting. Computations are series of re-arrangements of this spatial structures, 
representing ambient mobility. In this nominal calculus, names are the names of 
ambients rather than communication channels as in the pi calculus. Ambients are 
explicit boundaries: in the pi calculus, interaction depends on shared names — 
parties need to know the same communication channel to interact; in the ambient 
calculus, interaction depends on shared position — parties need to be inside the 
same ambient to interact . In this way, the ambient hierarchy regulates who may 
communicate with who. 

In Part III of these notes, we introduce the ambient calculus, show how it 
can model a programming language for mobile computation with features akin 
to Telescript, describe a series of type systems for ambients, and show how we 
can type aspects of mobile computation. 
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Scope of These Notes 

The goal of these notes is to introduce nominal calculi and their applications 
to security and mobility. The bulk of the notes consists of abridged versions of 
earlier articles [AG99, CGOOb, GG99, GGGOOa] concerning aspects of the three 
calculi we have discussed. Proof techniques and proofs omitted from these notes 
may be found in the full versions of the original articles. 

Many nominal calculi that have been applied to security or mobility are 
of course not covered. Two prominent examples are the join calculus and the 
seal calculus. The join calculus [FG96] is a variant of the pi calculus based 
on asynchronous communications; a distributed implementation [FGL“''96] has 
been used to implement the ambient calculus [FLSOO], amongst other things. 
The seal calculus [VG99] is a calculus of mobile agents, akin to the ambient 
calculus, but with a richer set of primitive operations; it forms the basis of the 
JavaSeal platform for mobile agents [BVOl]. 

Part I: The Pi Calculus 

This part of the notes introduces the pi calculus as a programming notation 
for studying security protocols. Section 2 introduces the syntax and informal 
semantics of the pi calculus. In Section 3 we explain an application of the pi 
calculus to the study of abstract security protocols. Section 4 ends this part 
with pointers to some of the main works on the pi calculus. 

Since the spi calculus of Part II is in fact an extension of the pi calculus of this 
part, we postpone formal definitions of operational semantics and equivalence 
until Part II. 



2 Outline of the Pi Calculus 

There are in fact several versions of the pi calculus. Here we review the syntax 
and semantics of a particular version. The differences with other versions are 
mostly orthogonal to our concerns. 

We assume an infinite set of names, to be used for communication channels, 
and an infinite set of variables. We let to, n, p, q, and r range over names, 
and let x, y, and z range over variables. The set of terms is defined by the 
grammar: 



Syntax of Terms: 



L, M, N ::= 


terms 


n 


name 


(M,N) 


pair 


0 


zero 


suc{M) 


successor 


X 


variable 
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In the standard pi calculus, names are the only terms. For convenience we 
have added constructs for pairing and numbers, (M, iV), 0, and suc{M). We have 
also distinguished variables from names. 

The set of processes is defined by the grammar: 

Syntax of Processes: 

P,Q,R::= processes 



case M of 0 : P suc{x) : Q integer case 



In (yn)P, the name n is bound in P. In M(x).P, the variable x is bound in P. 
In let (x, y) = M in P, the variables x and y are bound in P. In case M of 0 : 
P suc{x) : Q, the variable x is bound in the second branch, Q. We write P{M}x 
for the outcome of replacing each free occurrence of x in process P with the 
term M , and identify processes up to renaming of bound variables and names. 
We adopt the abbreviation M{N) for M{N).0. 

Intuitively, the constructs of the pi calculus have the following meanings: 

~ The basic computation and synchronisation mechanism in the pi calculus is 
interaction, in which a term N is communicated from an output process to 
an input process via a named channel, m. 

• An output process m{N).P is ready to output on channel m. If an in- 
teraction occurs, term N is communicated on m and then process P 
runs. 

• An input process m{x).P is ready to input from channel m. If an inter- 

action occurs in which N is communicated on m, then process P{N}x 
runs. 

(The general forms M{N).P and M{x).P of output and input allow for the 
channel to be an arbitrary term M . The only useful cases are for M to be 
a name, or a variable that gets instantiated to a name.) 

— A composition P \ Q behaves as processes P and Q running in parallel. Each 
may interact with the other on channels known to both, or with the outside 
world, independently of the other. 

— A restriction {vn)P is a process that makes a new, private name n, which 
may occur in P, and then behaves as P. 

— A replication \P behaves as an infinite number of copies of P running in 
parallel. 

— A match \M is N] P behaves as P provided that terms M and N are the 
same; otherwise it is stuck, that is, it does nothing. 



M{N).P 

M{x).P 

P\Q 

{un)P 

\P 

[M is N\ P 

0 

let {x, y) = M in P 



output 

input 

composition 

restriction 

replication 

match 

nil 

pair splitting 
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— The nil process 0 does nothing. 

Since we added pairs and integers, we have two new process forms: 

— A pair splitting process let (x,y) = M in P behaves as P{N'\x{L'\y if term 
M is the pair {N, L), and otherwise it is stuck. 

— An integer case process case M of 0 : P suc{x) : Q behaves as P if term M 
is 0, as Q{N}x if M is suc{N), and otherwise is stuck. 

We write P ~ Q to mean that the behaviours of the processes P and Q are 
indistinguishable. In other words, a third process R cannot distinguish running 
in parallel with P from running in parallel with Q; as far as R can tell, P and Q 
have the same properties (more precisely, the same safety properties) . We define 
the relation ~ in Part II as a form of testing equivalence. For now, it suffices to 
understand ~ informally. 



3 Security Examples Using Restricted Channels 

Next we show how to express some abstract security protocols in the pi calculus. 
In security protocols, it is common to find channels on which only a given set of 
principals is allowed to send data or listen. The set of principals may expand in 
the course of a protocol run, for example as the result of channel establishment. 
Remarkably, it is easy to model this property of channels in the pi calculus, via 
the restriction operation; the expansion of the set of principals that can access 
a channel corresponds to scope extrusion. 

3.1 A First Example 

Our first example is extremely basic. In this example, there are two principals A 
and B that share a channel, cab] only A and B can send data or listen on this 
channel. The protocol is simply that A uses cab for sending a single message 
M to B. In informal notation, we may write this protocol as follows: 

Message 1 A ^ R : M on cab 

A first pi calculus description of this protocol is: 

A{M) = 7^{M) 

B = CAs(a;).0 

Inst{M) = {vcab){A{M) \ B) 

The processes A{M) and B describe the two principals, and Inst{M) describes 
(one instance of) the whole protocol. The channel cab is restricted; intuitively, 
this achieves the effect that only A and B have access to cab- 

In these definitions, A{M) and Inst{M) are processes parameterised by M. 
More formally, we view A and Inst as functions that map terms to processes. 
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called abstractions, and treat the M’s on the left of = as bound parameters. 
Abstractions can of course be instantiated (applied); for example, the instantia- 
tion A(0) yields cab{0)- The standard rules of substitution govern application, 
forbidding parameter captures; for example, expanding InsticAs) would require 
a renaming of the bound occurrence of cab in the definition of Inst. 

The first pi calculus description of the protocol may seem a little futile be- 
cause, according to it, B does nothing with its input. A more useful and general 
description says that B runs a process F with its input. We revise our definitions 
as follows: 



A{M) ^ cXF{M) 

B = cab{x).F{x) 

Inst{M) = {vcab){A{M) \ B) 

Informally, F{x) is simply the result of applying F to x. More formally, F is 
an abstraction, and F{x) is an instantiation of the abstraction. We adopt the 
convention that the bound parameters of the protocol (in this case, M, cab, 
and x) cannot occur free in F . 

This protocol has two important properties: 

— Authenticity (or integrity): B always applies F to the message M that 
A sends; an attacker cannot cause B to apply F to some other message. 

— Secrecy: The message M cannot be read in transit from A to B\ if F does 
not reveal M, then the whole protocol does not reveal M . 

The secrecy property can be stated in terms of equivalences: if F{M) ~ 
F(M'), for any M, M' , then Inst{M) ~ Inst(M'). This means that if F(M) 
is indistinguishable from F{M'), then the protocol with message M is indistin- 
guishable from the protocol with message M' . 

There are many sensible ways of formalising the authenticity property. In 
particular, it may be possible to use notions of refinement or a suitable program 
logic. However, we choose to write authenticity as an equivalence, for economy. 
This equivalence compares the protocol with another protocol. Our intent is that 
the latter protocol serves as a specification. In this case, the specification is: 

A(M) = cI^(M) 

Bspec{M) = cab{x).F{M) 
lnstspec{M) = [vcab){A{M) \ 

^ spec (M)) 

The principal A is as usual, but the principal B is replaced with a vari- 
ant Bgpgc{M); this variant receives an input from A and then acts like B when 
B receives M. We may say that Bspec{M) is a “magical” version of B that knows 
the message M sent by A, and similarly Inst spec is a “magical” version of Inst. 

Although the specification and the protocol are similar in structure, the spec- 
ification is more evidently “correct” than the protocol. Therefore, we take the 
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Fig. 1. Structure of the Wide Mouthed Frog protocol 



following equivalence as our authenticity property: Inst(M) ~ Instspec(M), for 
any M. 

In summary, we have: 

Authenticity: Inst{M) ~ Instspec{M), 
for any M. 

Secrecy: Inst{M) ~ Inst(M') if F{M) ~ F{M'), 

for any M, M' . 

Each of these equivalences means that two processes being equated are indistin- 
guishable, even when an active attacker is their environment. Neither of these 
equivalences would hold without the restriction of channel cab- 

3.2 An Example with Channel Establishment 

A more interesting variant of our first example is obtained by adding a channel 
establishment phase. In this phase, before communication of data, the princi- 
pals A and B obtain a new channel with the help of a server S. 

There are many different ways of establishing a channel, even at the ab- 
stract level at which we work here. The one we describe is inspired by the Wide 
Mouthed Frog protocol [BAN89], which has the basic structure shown in Fig- 
ure 1. 

We consider an abstract and simplified version of the Wide Mouthed Frog 
protocol. Our version is abstract in that we deal with channels instead of keys; 
it is simplified in that channel establishment and data communication happen 
only once (so there is no need for timestamps) . In the next section we show how 
to treat keys and how to allow many instances of the protocol, with an arbitrary 
number of messages. 
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Informally, our version is: 

Message 1 A ^ S' : cab on cas 
Message 2 S — > i ? : cab on c$b 
Message 3 A-s- B \ M on cab 

Here cas is a channel that A and S share initially, csb is a channel that S and B 
share initially, and cab is a channel that A creates for communication with B. 
After passing the channel cab to B through S, A sends a message M on cab- 
Note that S does not use the channel, but only transmits it. 

In the pi calculus, we formulate this protocol as follows: 

A{M) = {i'cab)cas{cab)-cab{M) 

S = CAs{x).cg^{x) 

B = csB{x).x{y).F{y) 

Inst{M) = {iycAs){^csB){A{M) | S | H) 

Here we write F{y) to represent what B does with the message y that it receives, 
as in the previous example. The restrictions on the channels c^g, cgs, and cab 
reflect the expected privacy guarantees for these channels. The most salient new 
feature of this specification is the use of scope extrusion: A generates a fresh 
channel cab, and then sends it out of scope to B via S. We could not have 
written this description in formalisms such as CCS or CSP; the use of the pi 
calculus is important. 

For discussing authenticity, we introduce the following specification: 

A{M) = {vcab)cas {cab) -Cab {M) 

S = cas(x).c^{x) 

Bspec (M) = csB{x).x{y).F{M) 

Instspec{M) = {vCas){’^Csb){A{M) I S \ Bspec{M)) 

According to this specification, the message M is communicated “magically”: the 
process F is applied to the message M that A sends independently of whatever 
happens during the rest of the protocol run. 

We obtain the following authenticity and secrecy properties: 

Authenticity: Inst{M) ~ Instspec{M), 
for any M. 

Secrecy: Inst{M) ~ Inst(M') if F{M) ~ F{M'), 

for any M , M' . 

Again, these properties hold because of the scoping rules of the pi calculus. 

4 Discussion: The Pi Calculus 

In this part, we have briefly and informally introduced the pi calculus as a nota- 
tion for describing and specifying security protocols. In the next part, we extend 
these ideas to apply to cryptographic protocols. 
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Starting with the original presentation [MPW92] there is by now an extensive 
literature on the pi calculus, covered, for instance, by introductory [Mil99] and 
advanced [SWOl] textbooks. A good deal of the theory of the pi calculus concerns 
equational reasoning; two important works are on testing equivalence [BN95] 
and barbed bisimulation [MS92]. There are several works on logic [MPW93] and 
model checking [Dani96] for the pi calculus. 

The study of type systems for the pi calculus is a booming research area. 
We cite just three out of many papers. The simplest type system for the pi cal- 
culus is a system of channel sorts proposed by Milner [Mil99] . Pierce and San- 
giorgi [PS96] develop a more advanced system supporting subtyping. Igarashi 
and Kobayashi [IKOl] propose a generic framework in which to understand a va- 
riety of previous systems. 

Most versions of the pi calculus allow only passive data such as names to be 
transmitted on channels. Sangiorgi’s higher-order pi calculus [SWOl] is a variant 
in which processes may be transmitted on channels. Dam [Dani98] uses a second- 
order pi calculus to study security protocols. 

Part II: The Spi Calculus 

The spi calculus is an extension of the pi calculus with cryptographic primitives. 
It is designed for the description and analysis of security protocols, such as 
those for authentication and for electronic commerce. These protocols rely on 
cryptography and on communication channels with properties like authenticity 
and privacy. Accordingly, cryptographic operations and communication through 
channels are the main ingredients of the spi calculus. 

In Part I of these notes, we used the pi calculus (without extension) for 
describing protocols at an abstract level. The pi calculus primitives for channels 
are simple but powerful. Channels can be created and passed, for example from 
authentication servers to clients. The scoping rules of the pi calculus guarantee 
that the environment of a protocol (the attacker) cannot access a channel that it 
is not explicitly given; scoping is thus the basis of security. In sum, the pi calculus 
appears as a fairly convenient calculus of protocols for secure communication. 

However, the pi calculus does not express the cryptographic operations that 
are commonly used for implementing channels in distributed systems: it does not 
include any constructs for encryption and decryption, and these do not seem easy 
to represent. Since the use of cryptography is notoriously error-prone, we prefer 
not to abstract it away. We define the spi calculus in order to permit an explicit 
representation of the use of cryptography in protocols. 

There are many other notations for describing security protocols. Some, 
which have long been used in the authentication literature, have a fairly clear con- 
nection to the intended implementations of those protocols (e.g., [NS78, Lic93j). 
Their main shortcoming is that they do not provide a precise and solid basis 
for reasoning about protocols. Other notations (e.g., [BAN89]) are more for- 
mal, but their relation to implementations may be more tenuous or subtle. The 
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spi calculus is a middle ground: it is directly executable and it has a precise 
semantics. 

Because the semantics of the spi calculus is not only precise but intelligible, 
the spi calculus provides a setting for analysing protocols. Specifically, we can 
express security guarantees as equivalences between spi calculus processes. For 
example, we can say that a protocol keeps secret a piece of data X by stating 
that the protocol with X is equivalent to the protocol with X', for any X'. Here, 
equivalence means equivalence in the eyes of an arbitrary environment. The envi- 
ronment can interact with the protocol, perhaps attempting to create confusion 
between different messages or sessions. This definition of equivalence yields the 
desired properties for our security applications. Moreover, in our experience, 
equivalence is not too hard to prove. 

Although the definition of equivalence makes reference to the environment, 
we do not need to give a model of the environment explicitly. This is one of the 
main advantages of our approach. Writing such a model can be tedious and can 
lead to new arbitrariness and error. In particular, it is always difficult to express 
that the environment can invent random numbers but is not lucky enough to 
guess the random secrets on which a protocol depends. We resolve this conflict 
by letting the environment be an arbitrary spi calculus process. 

Our approach has some similarities with other recent approaches for rea- 
soning about protocols. Like work based on temporal logics or process algebras 
(e.g., [FG94, GM95, Low96, Sch96a]), our method builds on a standard concur- 
rency formalism; this has obvious advantages but it also implies that our method 
is less intuitive than some based on ad hoc formalisms (e.g., [BAN89]). As in 
some modal logics (e.g., [ABLP93, LABW92]), we emphasise reasoning about 
channels. As in state-transition models (e.g., [DY83, MGF87, Keni89, Mca92]), 
we are interested in characterising the knowledge of an environment. The unique 
features of our approach are its reliance on the powerful scoping constructs of 
the pi calculus; the radical definition of the environment as an arbitrary spi cal- 
culus process; and the representation of security properties, both integrity and 
secrecy, as equivalences. 

Our model of protocols is simpler, but poorer, than some models developed 
for informal mathematical arguments because the spi calculus does not include 
any notion of probability or complexity (cf. [BR95]). It would be interesting 
to bridge the gap between the spi calculus and those models, perhaps by giv- 
ing a probabilistic interpretation for our results. Recent work [LMMS98, AROO] 
makes progress in this direction. 

Remainder of Part II 

The remainder of this part is organised as follows. Section 5 extends the pi 
calculus with primitives for shared-key cryptography. Section 6 describes a series 
of protocol examples in the spi calculus. Sections 7 defines the formal semantics of 
the spi calculus. Section 8 discusses how to add primitives for hashing and public- 
key cryptography to the pi calculus. Finally, Section 9 offers some conclusions 
and discusses related work. 
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5 The Spi Calculus with Shared-Key Cryptography 

Just as there are several versions of the pi calculus, there are several versions of 
the spi calculus. These differ in particular in what cryptographic constructs they 
include. In this section we introduce a relatively simple spi calculus, namely the 
pi calculus extended with primitives for shared-key cryptography. We then write 
several protocols that use shared-key cryptography in this calculus. 

Throughout these notes, we often refer to the calculus presented in this sec- 
tion as “the” spi calculus; but we define other versions of the spi calculus in 
Section 8. 

The syntax of the spi calculus is an extension of that of the pi calculus. In 
order to represent encrypted messages, we add a clause to the syntax of terms: 



Syntax of Terms: 



L, M, N ::= 


terms 




as in Section 2 


{M}n 


shared-key encryption 


In order to represent decryption, we add a clause to the syntax of processes: 


Syntax of Processes: 




P,Q::= 


processes 




as in Section 2 


case L of {a;}Ar in P 


shared-key decryption 



The variable x is bound in P. 

Intuitively, the meaning of the new constructs is as follows: 

— The term {M}jv represents the ciphertext obtained by encrypting the term 
M under the key N using a shared-key cryptosystem such as DES [DES77]. 

— The process case L of {a ;} at in P attempts to decrypt the term L with the 
key N. If L is a ciphertext of the form {M}n, then the process behaves as 
P{M}x. Otherwise the process is stuck. 

Implicit in this definition are some standard but significant assumptions 
about cryptography: 

— The only way to decrypt an encrypted packet is to know the corresponding 
key. 

— An encrypted packet does not reveal the key that was used to encrypt it. 

— There is sufficient redundancy in messages so that the decryption algorithm 
can detect whether a ciphertext was encrypted with the expected key. 

It is not assumed that all messages contain information that allows each principal 
to recognise its own messages (cf. [BAN89]). 

The semantics of the spi calculus can be formalised in much the same way 
as the semantics of the pi calculus. We carry out this formalisation in Section 7. 
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Again, we write P ~ Q to mean that the behaviours of the processes P and Q 
are indistinguishable. The notion of indistinguishability is complicated by the 
presence of cryptography. As an example of these complications, consider the 
following process: 



P{M) = {vK)c{{M}k) 

This process simply sends M under a new key AT on a public channel c; the 
key K is not transmitted. Intuitively, we would like to equate P{M) and P{M'), 
for any M and M' , because an observer cannot discover K and hence cannot tell 
whether M or M' is sent under K . On the other hand, P{M) and P{M') are 
clearly different, since they transmit different messages on c. Our equivalence ~ 
is coarse-grained enough to equate P{M) and P{M'). 

6 Security Examples Using Shared-Key Cryptography 

The spi calculus enables more detailed descriptions of security protocols than 
the pi calculus. While the pi calculus enables the representation of channels, 
the spi calculus also enables the representation of the channel implementations 
in terms of cryptography. In this section we show a few example cryptographic 
protocols. 

As in the pi calculus, scoping is the basis of security in the spi calculus. In 
particular, restriction can be used to model the creation of fresh, unguessable 
cryptographic keys. Restriction can also be used to model the creation of fresh 
nonces of the sort used in challenge-response exchanges. 

Security properties can still be expressed as equivalences, although the notion 
of equivalence is more delicate, as we have discussed. 

6.1 A First Cryptographic Example 

Our first example is a cryptographic version of the example of Section 3.1. We 
consider two principals A and B that share a key Kab] in addition, we assume 
there is a public channel cab that A and B can use for communication, but 
which is in no way secure. The protocol is simply that A sends a message M 
under Kab to B, on cab- 

Informally, we write this protocol as follows: 

Message I A^ B ■. {M}kab on cab 

In the spi calculus, we write: 

A{M) = cab{{M}kab) 

B = CAB{x).case x of {v}kab F{y) 

Inst{M) = {vKab){A{M) \ B) 
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According to this definition, A sends {M}kab on cab while B listens for a mes- 
sage on Cab- Given such a message, B attempts to decrypt it using Kab] if this 
decryption succeeds, B applies F to the result. The assumption that A and B 
share Kab gives rise to the restriction on Kab, which is syntactically legal and 
meaningful although Kab is not used as a channel. On the other hand, cab is 
not restricted, since it is a public channel. Other principals may send messages 
on CAB I so B may attempt to decrypt a message not encrypted under Kab', in 
that case, the protocol will get stuck. We are not concerned about this possibil- 
ity, but it would be easy enough to avoid it by writing a slightly more elaborate 
program for B. 

We use the following specification: 



A{M) = cab{{M}kab) 

Bspec{M) = CAB (x). case X of {u}kab « F{M) 

InstspeciM) = {uKabKA{M) \ Bspec{M)) 

and we obtain the properties: 

Authenticity: Inst{M) ~ Inst special) , 
for any M . 

Secrecy: Inst{M) ~ Inst(M') if F{M) ~ F{M'), 

for any M, M' . 

Intuitively, authenticity holds even if the key Kab is somehow compromised 
after its use. Many factors can contribute to key compromise, for example in- 
competence on the part of protocol participants, and malice and brute force on 
the part of attackers. We cannot model all these factors, but we can model de- 
liberate key publication, which is in a sense the most extreme of them. It suffices 
to make a small change in the definitions of B and Bgpec, so that they send 
Kab on a public channel after receiving {M}xab- This change preserves the 
authenticity equation, but clearly not the secrecy equation. 

6.2 An Example with Key Establishment 

In cryptographic protocols, the establishment of new channels often means the 
exchange of new keys. There are many methods (most of them flawed) for key 
exchange. The following example is the cryptographic version of that of Sec- 
tion 3.2; it uses a simplified (one-shot) form of the Wide Mouthed Frog key 
exchange. 

In the Wide Mouthed Frog protocol, the principals A and B share keys 
Kas £md Ksb respectively with a server S. When A and B want to communicate 
securely, A creates a new key Kab, sends it to the server under Kas, and 
the server forwards it to B under Ksb- All communication being protected by 
encryption, it can happen through public channels, which we write cas, csb. 
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and Cab- Informally, a simplified version of this protocol is: 

Message 1 A ^ S' : {Kab}kas 
Message 2 S ^ B : {Kab}ksb on csb 
Message 3 B : {M}kab on cab 

In the spi calculus, we can express this message sequence as follows: 

A{M) = {i'Kab){'^{{Kab}kas)-(^ab{{M}kab)) 

S = CAs{x)-case x of {y}KAs « 

B = csB{x).case x of {u}ksb 

CAB{z)-case z of {tc}y in F{w) 

Inst{M) = {iyKAs){^KsB){A{M) | S | S) 

where F{w) is a process representing the rest of the behaviour of B upon re- 
ceiving a message w. Notice the essential use of scope extrusion: A generates the 
key Kab and sends it out of scope to B via S. 

In the usual pattern, we introduce a specification for discussing authenticity: 

A{M) = (vKab){'c^{{Kab}kas)-(^ab{{M}kab)) 

S = CAs{x).case x of {y}KAs « 

Bspec(M) = csB{x).case x of {y}KsB 

CAB{z).case z of {w}y in F{M) 

InstspeciM) = {vKas){.vKsb){.A{M) \ S \ Bspec{M)) 

One may be concerned about the apparent complexity of this specification. 
On the other hand, despite its complexity, the specification is still more evidently 
“correct” than the protocol. In particular, it is still evident that Bspec{M) ap- 
plies F to the data M from A, rather than to some other message chosen as the 
result of error or attack. 

We obtain the usual properties of authenticity and secrecy: 

Authenticity: Inst{M) ~ Instspec{M), 
for any M. 

Secrecy: Inst{M) ~ Inst(M') if F{M) ~ F{M'), 

for any M, M' . 

6.3 A Complete Authentication Example (with a Flaw) 

In the examples discussed so far, channel establishment and data communication 
happen only once. As we demonstrate now, it is a simple matter of program- 
ming to remove this restriction and to represent more sophisticated examples 
with many sessions between many principals. However, as the intricacy of our 
examples increases, so does the opportunity for error. This should not be con- 
strued as a limitation of our approach, but rather as the sign of an intrinsic 
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difficulty: many of the mistakes in authentication protocols arise from confusion 
between sessions. 

We consider a system with a server S and n other principals. We use the 
terms swc(O), sitc(swc(0)), . . . , which we abbreviate to 1, 2, . . . , as the names 
of these other principals. We assume that each principal has an input channel; 
these input channels are public and have the names ci, C 2 , . . . , c„ and Cs- We 
also assume that the server shares a pair of keys with each other principal, one 
key for each direction: principal i uses key Kig to send to S and key Kgi to 
receive from S, for 1 < i < n. 

We extend our standard example to this system of n + 1 principals, with the 
following message sequence: 

Message 1 A — > S' : A, {B, Kab}kas 
Message 2 S ^ B : {A,Kab}ksb on cb 

Message 3 A ^ B : A, {M}kab on cb 

Here A and B range over the n principals. The names A and B appear in 
messages in order to avoid ambiguity; when these names appear in clear, they 
function as hints that help the recipient choose the appropriate key for decryption 
of the rest of the message. The intent is that the protocol can be used by any 
pair of principals, arbitrarily often; concurrent runs are allowed. As it stands, 
the protocol has obvious flaws; we discuss it in order to explain our method for 
representing it in the spi calculus. 

In our spi calculus representation, we use several convenient abbreviations. 
Firstly, we rely on pair splitting on input and on decryption: 

c{xi,X 2 )-P = c{y).let (xi,X 2 ) = y in P 

case L of {a;i,a; 2 }Ar in P = case L of {y}N in 

let (xi,X 2 ) = y in P 

where variable y is fresh. Secondly, we need the standard notation for the com- 
position of a finite set of processes. Given a finite family of processes Pi, . . . , Pfe, 
we let HiGi k Pi their fc-way composition Pi | • • • | Pfc. Finally, we omit the 
inner parentheses from an encrypted pair of the form {(TV, 7V')}jv'', and simply 
write {N, N'}a[" , as is common in informal descriptions. 

Informally, an instance of the protocol is determined by a choice of parties 
(who is A and who is B) and by the message sent after key establishment. More 
formally, an instance / is a triple (i,j,M) such that i and j are principals and 
M is a message. We say that i is the source address and j the destination address 
of the instance. Moreover, we assume that there is an abstraction F representing 
the behaviour of any principal after receipt of Message 3 of the protocol. For an 
instance {i,j, M) that runs as intended, the argument to P is the triple {i,j, M). 

Given an instance {i,j, M), the following process corresponds to the role of A: 

Send{i,j,M) = {i, K}k,s)) I ^iihW}K))) 

The sending process creates a key K and sends it to the server, along with 
the names i and j of the principals of the instance. The sending process also 
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sends M under iC, along with its name i. We have put the two messages in 
parallel, somewhat arbitrarily; putting them in sequence would have much the 
same effect. 

The following process corresponds to the role of B for principal j : 

Rccvi^j^ = Cj (^y cipher') ■ CCLS 6 ycipher of 
^ cipher') A ^-5 ^a\ 

case Zeipher of \Zplain^Xkey jj Z^plain') 

The receiving process waits for a message y cipher from the server, extracts a key 
Xkey from this message, then waits for a message Zeipher under this key, and 
finally applies F to the name xa of the presumed sender, to its own name j, and 
to the contents Zpiain of the message. The variables xa and za are both intended 
as the name of the sending process, so they are expected to match. 

The server S is the same for all instances: 

S — C-s{x A ■; X cipher') • 

^[^A i] CQS6 Xcipher \^B:^key^Kis 

Ujel..ni^B is i]-^{{XA,Xkey}Ksj) 

The variable Xa is intended as the name of the sending process, Xb &s the name 
of the receiving process, Xkey as the new key, and Xdpher as the encrypted part of 
the first message of the protocol. In the code for the server, we program an n-way 
branch on the name xa by using a parallel composition of processes indexed by 
i € l..n. We also program an n-way branch on the name Xb, similarly. (This 
casual use of multiple threads is characteristic of the pi calculus; in practice the 
branch could be implemented more efficiently, but here we are interested only in 
the behaviour of the server, not in its efficient implementation.) 

Finally we define a whole system, parameterised on a list of instances: 

Sys{h,...J^) = {vKis){i^Ksj) 

{Send{Ii) I • • • I Send(Im) \ 

\S\ 

lRecv{l) I ■ ■ ■ I IRecv(n)) 

where (i'Kis)(i^Ksj) stands for: 



■ ■ ■ (i^Kns)(i'Ksi) ■ ■ ■ (vKsn) 



The expression Sys{Ii , . . . , Im) represents a system with m instances of the pro- 
tocol. The server is replicated; in addition, the replication of the receiving pro- 
cesses means that each principal is willing to play the role of receiver in any 
number of runs of the protocol in parallel. Thus, any two runs of the protocol 
can be simultaneous, even if they involve the same principals. 

As before, we write a specification by modifying the protocol. For this spec- 
ification, we revise the sending and the receiving processes, but not the server: 
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Send specie = {up){Send{iJ,p) | p(x).i^(i, j, M)) 

ReCV speci^j^ — C j (^y cipher^ ■ 

case Pcipher ^fcey 

^cipher ).[XA is Za] 

CCIS6 Zcipfier {-^pZam}a:fcej, i'^ 

^plain (*) 

Sys,p,,{Iu-..Jm) = {i'Kis){uKsi) 

(Sendspecih) | • • ■ | Send spec (Im) I 

! 5 | 

\RecVspec{^) I ■ ■ ■ I ^-Recv spec (n)) 

In this specification, the sending process for instance (i, j, M) is as in the imple- 
mentation, except that it sends a fresh channel name p instead of M , and runs 
F{i,j,M) when it receives any message on p. The receiving process in the spec- 
ification is identical to that in the implementation, except that F{yA, j , Zpiain) 
is replaced with Zpiaini*), where the symbol * represents a fixed but arbitrary 
message. The variable Zpiain will be bound to the fresh name p for the corre- 
sponding instance of the protocol. Thus, the receiving process will signal on p, 
triggering the execution of the appropriate process F{i,j,M). 

A crucial property of this specification is that the only occurrences of F are 
bundled into the description of the sending process. There, F is applied to the 
desired parameters, Hence it is obvious that an instance will 

cause the execution of F{i/ ,j', M') only if i' is i, f is j, and M' is M. Therefore, 
despite its complexity, the specification is more obviously “correct” than the 
implementation. 

Much as in previous examples, we would like the protocol to have the follow- 
ing authenticity property: 

Sys{h 1 ' • ■ 1 ) ~ Sys 

spec ih ) • • ■ ) Im): 

for any instances Ji, . . . , Im- 

Unfortunately, the protocol is vulnerable to a replay attack that invalidates the 
authenticity equation. Consider the system Sys{I,I') where I = {i,j,PI) and 
/' = An attacker can replay messages of one instance and get them 

mistaken for messages of the other instance, causing M to be passed twice to F. 
Thus, Sys{I,F) can be made to execute two copies of F{i,j,M). In contrast, 
no matter what an attacker does, Sys^p^^{I^F) will run each of F{i,j,M) and 
Fihj: FI') at most once. The authenticity equation therefore does not hold. (We 
can disprove it formally by defining an attacker that distinguishes Sys {I, I') and 
Sys specie n') I within the spi calculus.) 

6.4 A Complete Authentication Example (Repaired) 

Now we improve the protocol of the previous section by adding nonce hand- 
shakes as protection against replay attacks. The Wide Mouthed Frog protocol 
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Send{i,j,M) = cs{i) \ 

Ci ( 3 ^ nonce )• (^^^) (C|S ( {A; i; 5 ^TioTice )) | ( (l; ) ) ) 

S = Cs{XA).UiGl..J^^^ {j^Ns){-^{Ns) I 

CS (^A 5 ^cip/ier) ■ i] 

case X cipher of \y Aj X B i X heyi Xnonce} Kj^g 

Uj^i..n[y^ [ Xnonce is Ns] 

{cj{*) I cs{y nonce )-Cj{{S, i,i,Xkey ; ynonce 

Recv{j) = Cj{w).{vNB){cs{NB) \ 

Cj {^y cipher^ • 

CdS€ ycipher of \^X S i X A-j X B -i X]zcyiynonce\ K gj "id 
Uiei-.ni^s is S] [XA isi] [xb ts ^ [y nonce is A^s] 

Cj'(^A; ^cipherW^A iS Xa] 

CQjSG Zeipher of \^Zplain} xj.^y if^ F (^i_j j ^ Zplain^^ 

Sys{h, . . . ,/m) = {uKis)[vKsj) 

{Send{h) I ••• I Send{IA I 
! 5 | 

\Recv{l) I • ■ • I \Recv{n)) 

Fig. 2. Formalisation of the Seven-Message protocol 



uses timestamps instead of handshakes. The treatment of timestamps in the spi 
calculus is possible, but it requires additional elements, including at least a rudi- 
mentary account of clock synchronisation. Protocols that use handshakes are 
fundamentally more self-contained than protocols that use timestamps; there- 
fore, handshakes make for clearer examples. 

Informally, our new protocol is: 

Message 1 A — > S' : A on cs 

Message 2 S ^ A : Ns on ca 

Message 3 A ^ S : A, {A, A, B, Kab,Ns}kas on cs 
Message A S ^ B ■. * on c_b 

Message 5 B ^ S : Nb on cs 

Message 6 S — *■ // : {S, A, B, Kab, Nb}ksb on cb 

Message 7 A ^ B ■. A, {M}kab on cb 

Messages 1 and 2 are the request for a challenge and the challenge, respectively. 
The challenge is Ns, a nonce created by S; the nonce must not have been used 
before for this purpose. Obviously the nonce is not secret, but it must be unpre- 
dictable (for otherwise an attacker could simulate a challenge and later replay the 
response [AN96]). In Message 3, A says that A and B can communicate under 
Kab, sometime after receipt of Ns- All the components A, B, Kab, Ns appear 
explicitly in the message, for safety [AN96], but A could perhaps be elided. The 
presence of Ns in Message 3 proves the freshness of the message. In Message 4, 
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* represents a fixed but arbitrary message; S uses * to signal that it is ready for 
a nonce challenge Ng from B. In Message 6, S says that A says that A and B 
can communicate under K^g, sometime after receipt of Ng. The first field of 
the encrypted portions of Messages 3 and 6 {A or S) is included in order to 
distinguish these messages; it serves as a “direction bit”. Finally, Message 7 is 
the transmission of data under Kab- 

The messages of this protocol have many components. For the spi calculus 
representation it is therefore convenient to generalise our syntax of pairs and 
pair splitting to arbitrary tuples. We use the following standard abbreviations: 

{N^,...,Nk+i) = {{N^,...,Nk),Nk+i) 

let (xi, . . . , Sfe+i) = N in P = let (y, Xk+i) = N in 

let {xi, . . . ,Xk) = y in P 



where variable y is fresh. 

In the spi calculus, we represent the nonces of this protocol as newly created 
names. We obtain the spi calculus expressions given in Figure 2. In those expres- 
sions, the names Ng and Ng represent the nonces. The variable subscripts are 
hints that indicate what the corresponding variables should represent; for exam- 
ple, XA, x'j^, yA, and za are all expected to be the name of the sending process, 
and Xnonce and y nonce are expected to be the nonces generated by S and B, 
respectively. 

The definition of Sys^p^^ is exactly analogous to that of the previous section, 
so we omit it. We obtain the authenticity property: 

Sys{h j • ■ • j Im ) ~ Sys 

spec ih ! ■ ■ ■ ! Im ) I 

for any instances /i, . . . , 1^- 

This property holds because of the use of nonces. In particular, the replay attack 
of Section 6.3 can no longer distinguish Sys{Ii , . . . , Im) and Sys^p^^{Ii , . . . , Im)- 

As a secrecy property, we would like to express that there is no way for an 
external observer to tell apart two executions of the system with identical partic- 
ipants but different messages. The secrecy property should therefore assert that 
the protocol does not reveal any information about the contents of exchanged 
messages if none is revealed after the key exchange. 

In order to express that no information is revealed after the key exchange, 
we introduce the following definition. We say that a pair of instances (i,j,M) 
and {i',j', M') is indistinguishable if the two instances have the same source and 
destination addresses {i = i' and j = j') and if F{i,j, M) ~ F{i,j, M'). 

Our definition of secrecy is that, if each pair (Ji, Ji), . . . , (Im, Jm) is indistin- 
guishable, then Sys{Ii , . . . , Im) — Sys{Ji , . . . , Jm)- This means that an observer 
cannot distinguish two systems parameterised by two sets of indistinguishable 
instances. This property holds for our protocol. 

In summary, we have: 
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Authenticity: Sys{Ii , . . . ,7^) ~ Sys^p^^ih, . . .,7m), 
for any instances Ii, . . . , Im- 
Secrecy: Sys{h,. . . ,Im) — Sys{Ji 

if each pair (Ii, Ji), . . . , {Im , Jm ) 
is indistinguishable. 

We could ask for a further property of anonymity, namely that the source 
and the destination addresses of instances be protected from eavesdroppers. How- 
ever, anonymity holds neither for our protocol nor for most current, practical 
protocols. It would be easy enough to specify anonymity, should it be relevant. 

6.5 Discussion of the Examples 

As these examples show, writing a protocol in the spi calculus is essentially anal- 
ogous to writing it in any programming language with suitable communication 
and encryption libraries. The main advantage of the spi calculus is its formal 
precision. 

Writing a protocol in the spi calculus may be a little harder than writing it 
in some of the notations common in the literature. On the other hand, the spi 
calculus versions are more detailed. They make clear not only what messages 
are sent but how the messages are generated and how they are checked. These 
aspects of the spi calculus descriptions add complexity, but they enable finer 
analysis. 



7 Formal Semantics of the Spi Calculus 

In this section we give a brief formal treatment of the spi calculus. In Section 7.1 
we introduce the reaction relation; P — > Q means there is a reaction amongst 
the subprocesses of P such that the whole can take a step to process Q. Reaction 
is the basic notion of computation in both the pi calculus and the spi calculus. 
In Section 7.2 we give a precise definition of the equivalence relation which 
we have used for expressing security properties. 



Syntactic Conventions 

We write fn{M) and fn{P) for the sets of names free in term M and process P 
respectively. Similarly, we write fv{M) and fv{P) for the sets of variables free 
in M and P respectively. We say that a term or process is closed to mean that 
it has no free variables. (To be able to communicate externally, a process must 
have free names.) The set Proc = {P \ fv{P) = 0} is the set of closed processes. 

7.1 The Reaction Relation 

The reaction relation is a concise account of computation in the pi calculus 
introduced by Milner [Mil92], inspired by the Chemical Abstract Machine of 
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Berry and Boudol [BB90]. One thinks of a process as consisting of a chemical 
solution of molecules waiting to react. A reaction step arises from the interaction 
of the adjacent molecules m{N).P and m{x).Q, as follows: 

(React Inter) m{N).P \ m(x).Q P \ Q{N}x 

Just as one might stir a chemical solution to allow non-adjacent molecules 
to react, we define a relation, structural equivalence, that allows processes to be 
rearranged so that the rule above is applicable. We first define the reduction 
relation > on closed processes: 

Reduction: 

(Red Repl) !P > P | !P 

(Red Match) [M is M]P > P 

(Red Let) let (x, y) = (M, N) in P > P{M}x{N}y 

(Red Zero) case 0 0 / 0 : P suc(x) : Q > P 

(Red Sue) case suc{M) of 0 : P suc{x) : Q > Q{M}x 
(Red Decrypt) case {M}n of in P > P{M}a: 



We let structural equivalence, =, be the least relation on closed processes that 
satisfies the following equations and rules: 

Structural Congruence: 

(Struct Nil) P I 0 = P 

(Struct Comm) P \ Q = Q \ P 

(Struct Assoc) P | (Q | P) = (P | Q) | P 
(Struct Switch) (ym)(yn)P = (yn)(ym)P 

(Struct Drop) {vn)Q = 0 

(Struct Extrusion) {vn){P \ Q) = P \ {vn)Q ii n fn{P) 

(Struct Red) (Struct Rcfl) (Struct Symm) 

P>Q P = Q 

P = Q P = P Q = P 

(Struct Trans) (Struct Par) (Struct Res) 

P = Q Q = R P = P' P = P' 

P = R P\Q = P' \ Q {vm)P = {vm)P' 



Now we can complete the formal description of the reaction relation. We let 
the reaction relation, be the least relation on closed processes that satisfies 
the rule (React Inter) displayed above and the following rules: 

Reaction: 

(React Struct) (React Par) (React Res) 

P = P' P' ^Q' Q' = Q P ^ P' P ^ P' 
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This definition of the reaction relation corresponds to the informal description 
of process behaviour given in Sections 2 and 5. 

As an example, we can use the definition of the reaction relation to show the 
behaviour of the protocol of Section 6.2: 

Inst{M) = {vKas){vKsb){A{M) | S' | i?) 

— > {vKas){vKsb){^'Kab) 

{cab{{M}kab) I c^{{Kab}ksb) I B) 

—> {vKas){vKsb){vKab) 

{cab{{M}kab) I 

CAB{z).case z of {w}kab in F{w)) 

— > {vKas){vKsb){vKab)F{M) 

= F{M) 

The last step in this calculation is justified by our general convention that none 
of the bound parameters of the protocol (including, in this case, Kas, Ksb, and 
Kab) occurs free in F. 

7.2 Testing Equivalence 

In order to define equivalence, we first define a predicate that describes the 
channels on which a process can communicate. We let a barb, j3, be an input or 
output channel, that is, either a name m (representing input) or a co-name m 
(representing output). For a closed process P, we define the predicate P exhibits 
barb (3, written P [ (3, hy the following rules: 

Exhibition of a Barb: 

(Barb In) (Barb Out) (Barb Par) 

PIP 

m{x).P [m m{M).P [m P\QiP 

(Barb Res) (Barb Struct) 

P I P P ^ {m,m} P = Q Q I P 
{vm)P [ j3 PIP 



Intuitively, P [ P holds just if P is a closed process that may input or output 
immediately on barb p. The convergence predicate Pi^P holds if P is a closed 
process that exhibits P after some reactions: 

Convergence to a Barb: 



(Conv Barb) (Conv React) 
PIP P^Q QW 
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We let a test consist of any closed process R and any barb j3. A closed 
process P passes the test if and only if {P \ The notion of testing gives 

rise to a testing equivalence on the set Proc of closed processes: 

P ~ Q = for any test (R,P), 

{P I R)ii-f3 if and only if (Q | R)i}-f3 

The idea of testing equivalence comes from the work of De Nicola and Hen- 
nessy [DH84]. Despite superficial differences, we can show that our relation ~ 
is a version of De Nicola and Hennessy’s may-testing equivalence. As De Nicola 
and Hennessy have explained, may-testing corresponds to partial correctness (or 
safety), while must-testing corresponds to total correctness. Like much of the 
security literature, our work focuses on safety properties, hence our definitions. 

A test neatly formalises the idea of a generic experiment or observation an- 
other process (such as an attacker) might perform on a process, so testing equiv- 
alence captures the concept of equivalence in an arbitrary environment. One 
possible drawback of testing equivalence is that it is sensitive to the choice of 
language [BN95]. However, our results appear fairly robust in that they carry 
over smoothly to some extensions of our calculus. 

8 Further Cryptographic Primitives 

Although so far we have discussed only shared-key cryptography, other kinds of 
cryptography are also easy to treat within the spi calculus. In this section we 
show how to handle cryptographic hashing, public-key encryption, and digital 
signatures. We add syntax for these operations to the spi calculus and give their 
semantics. We thus provide evidence that our ideas are applicable to a wide 
range of security protocols, beyond those that rely on shared- key encryption. 
We believe that we may be able to deal similarly with Diffie-Hellman techniques 
and with secret sharing. However, protocols for oblivious transfer and for zero- 
knowledge proofs, for example, are probably beyond the scope of our approach. 

8.1 Hashing 

A cryptographic hash function has the properties that it is very expensive to 
recover an input from its image or to find two inputs with the same image. 
Functions such as SHA and RIPE-MD are generally believed to have these prop- 
erties [Sch96b]. 

When we represent hash functions in the spi calculus, we pretend that oper- 
ations that are very expensive are altogether impossible. We simply add a con- 
struct to the syntax of terms of the spi calculus: 

Extension for Hashing: 

L, M, N ::= terms 

as in Section 5 

p[{M) hashing 
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The syntax of processes is unchanged. Intuitively, H{M) represents the hash 
of M. The absence of a construct for recovering M from H{M) corresponds to 
the assumption that H cannot be inverted. The lack of any equations H{M) = 
H{M') corresponds to the assumption that H is free of collisions. 



8.2 Public-Key Encryption and Digital Signatures 



Traditional public-key encryption systems are based on key pairs. Normally, one 
of the keys in each pair is private to one principal, while the other key is public. 
Any principal can encrypt a message using the public key; only a principal that 
has the private key can then decrypt the message [DH76, RSA78]. 

We assume that neither key can be recovered from the other. We could just 
as easily deal with the case where the public key can be derived from the private 
one. Much as in Section 5, we also assume that the only way to decrypt an 
encrypted packet is to know the corresponding private key; that an encrypted 
packet does not reveal the public key that was used to encrypt it; and that there 
is sufficient redundancy in messages so that the decryption algorithm can detect 
whether a ciphertext was encrypted with the expected public key. 

We arrive at the following syntax for the spi calculus with public-key encryp- 
tion. (This syntax is concise, rather than memorable.) 



Extensions for Public-Key Cryptography: 



L,M,N ■.■= 

M+ 

M~ 



terms 

as in Section 5 
public part 
private part 
public-key encryption 



P,Q:-.= 

case L of {[a ;]} at in P 



processes 

as in Section 5 
decryption 



If M represents a key pair, then M'*' represents its public half and M~ represents 
its private half. Given a public key N, the term {[MJIat represents the result of 
the public-key encryption of M with N. In case L of {[xJIat inP, the variable x 
is bound in P. This construct is useful when TV is a private key K~] then it 
binds X to the M such that {[T17 ]}a-+ is L, if such an M exists. 

It is also common to use key pairs for digital signatures. Private keys are used 
for signing, while public keys are used for checking signatures. We can represent 
digital signatures through the following extended syntax: 

Extensions for Digital Signatures: 

L, TkT, TV ::= terms 

as above 

^M]\n private-key signature 
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P,Q ■.:= processes 

as above 

case N of |{a;}]M in P signature check 



Given a private key N, the term |{M}]Ar represents the result of the signature 
of M with N. Again, variable x is bound in P in the syntax case N of |{a;}]M inP. 
This construct is dual to case L of {[x]}Af inP. The new construct is useful when 

is a public key then it binds x to the M such that is L, if such 

an M exists. (Thus, we are assuming that M can be recovered from the result 
of signing it; but there is no difficulty in dropping this assumption.) 

Formally, the semantics of the new constructs is captured with two new rules 
for the reduction relation: 

(Red Public Decrypt) case {[M]}jv+ of {[a:]} at- in P > P{M}x 
(Red Signature Check) case of Ka;}]Ar+ in P > P{M}x 

As a small example, we can write the following public-key analogue for the 
protocol of Section 6 . 1 : 

A{M) ^ cI^({[M, 

B = CAB(x).case x of {[y]}^- in 

let (2/1, 2/2) =y in 
case 2/2 of [{2;}];^+ in 
[H{yi) is z] F(yi) 

Inst{M) = {vKa){vKb){A{M) \ B) 

In this protocol, A sends M on the channel cab , signed with A’s private key and 
encrypted under R’s public key; the signature is applied to a hash of M rather 
than to M itself. On receipt of a message on cab, B decrypts using its private 
key, checks A’s signature using A’s public key, checks the hash, and applies F to 
the body of the message (to M). The key pairs Ka and Kb are restricted; but 
there would be no harm in sending their public parts and on a public 
channel. 

Other formalisations of public-key cryptography are possible, perhaps even 
desirable. In particular, we have represented cryptographic operations at an ab- 
stract level, and do not attempt to model closely the properties of any one 
algorithm. We are concerned with public-key encryption and digital signatures 
in general rather than with their RSA implementations, say. The RSA system 
satisfies equations that our formalisation does not capture. For example, in the 
RSA system, equals M. Abadi and Fournet [AFOl] investigate 

a pi calculus in which such equations may be imposed on terms. 

9 Discussion: The Spi Calculus 

In this part, we have applied the spi calculus to the description and analysis 
of security protocols. We showed how to represent protocols and how to ex- 
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press their security properties. Our model of protocols takes into account the 
possibility of attacks, but does not require writing explicit specifications for an 
attacker. In particular, we express secrecy properties as simple equations that 
mean indistinguishability from the point of view of an arbitrary attacker. To our 
knowledge, this sharp treatment of attacks has not been previously possible. 

As examples, we chose protocols of the sort commonly found in the authenti- 
cation literature. Although our examples are small, we have found them instruc- 
tive and encouraging. In particular, there seems to be no fundamental difficulty 
in writing other kinds of examples, such as protocols for electronic commerce. 
Unfortunately, the specifications for those protocols do not yet seem to be fully 
understood, even in informal terms [Mao96]. 

Several proof techniques for the spi calculus have been developed since the 
work reported in this part of the notes was completed. Several researchers 
have devised proof techniques for equational reasoning in spi and its general- 
isations [AG98, BNP99, AFOl]. A type system due to Abadi [Aba99] can prove 
equationally-specified secrecy properties including the one stated in Section 6.4. 
There is no comparable type system for proving equationally-specified authen- 
ticity properties. Still, recent work on type systems for the spi calculus [G.IOl] 
allow the proof by type-checking of authenticity properties specified using the 
correspondence assertions of Woo and Lam [WL93] . 

Apart from the spi calculus, other nominal calculi to have been applied to 
cryptographic protocols include the sjoin calculus [AFG98], a version of the 
join calculus equipped with abstract cryptographic primitives. It is surprisingly 
difficult to encode encryption within the pi calculus; Amadio and Prasad [AP99] 
investigate one such encoding. 



Part III: The Ambient Calculus 

The ambient calculus is a nominal calculus whose basic abstraction, the ambient, 
represents mobile, nested, computational environments, with local communica- 
tions. Ambients can represent the standard components of distributed systems, 
such as nodes, channels, messages, and mobile code. They can also represent sit- 
uations where entire active computational environments are moved, as happens 
with mobile computing devices, and with multi-threaded mobile agents. 

This part of the notes introduces the ambient calculus, and explains how we 
can regulate aspects of mobility by typing. It is organised as follows. In Sec- 
tion 10, we informally motivate the ambient abstraction, and then in Section 11 
we present the basic untyped ambient calculus. Next, in Section 12, we motivate 
the development of type systems for the ambient calculus. In Section 13 we in- 
formally introduce a type system that only tracks communications. In Section 14 
we give a precise definition of the same system, and a subject reduction result. 
Section 15 and 16 enrich this system to regulate the mobility of ambients. In 
Section 17, to illustrate the expressiveness of the ambient calculus and its type 
system, we present a typed encoding of a distributed programming language. 
Section 18 concludes. 
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10 Motivation for Ambients 

There are two distinct areas of work in mobility: mobile computing, concern- 
ing computation that is carried out in mobile devices (laptops, personal digital 
assistants, etc.), and mobile computation, concerning mobile code that moves 
between devices (applets, agents, etc.). We aim to describe all these aspects of 
mobility within a single framework that encompasses mobile agents, the ambi- 
ents where agents interact and the mobility of the ambients themselves. 

The inspiration for this work comes from the potential for mobile computa- 
tion over the World-Wide Web. The geographic distribution of the Web natu- 
rally calls for mobility of computation, as a way of flexibly managing latency and 
bandwidth. Because of recent advances in networking and language technology, 
the basic tenets of mobile computation are now technologically realizable. The 
high-level software architecture potential, however, is still largely unexplored, 
although it is being actively investigated in the coordination and agents com- 
munities. 

The main difficulty with mobile computation on the Web is not in mobility 
per se, but in the handling of administrative domains. In the early days of the 
internet one could rely on a flat name space given by IP addresses; knowing the 
IP address of a computer would very likely allow one to talk to that computer in 
some way. This is no longer the case: firewalls partition the internet into admin- 
istrative domains that are isolated from each other except for rigidly controlled 
pathways. System administrators enforce policies about what can move through 
firewalls and how. 

Mobility requires more than the traditional notion of authorization to run or 
to access information in certain domains: it involves the authorization to enter or 
exit certain domains. In particular, as far as mobile computation is concerned, 
it is not realistic to imagine that an agent can migrate from any point A to 
any point B on the internet. Rather, an agent must first exit its administrative 
domain (obtaining permission to do so), enter someone else’s administrative 
domain (again, obtaining permission to do so) and then enter a protected area 
of some machine where it is allowed to run (after obtaining permission to do 
so). Access to information is controlled at many levels, thus multiple levels of 
authorization may be involved. Among these levels we have: local computer, local 
area network, regional area network, wide-area intranet and internet. Mobile 
programs must be equipped to navigate this hierarchy of administrative domains, 
at every step obtaining authorization to move further. Similarly, laptops must be 
equipped to access resources depending on their location in the administrative 
hierarchy. Therefore, at the most fundamental level we need to capture notions 
of locations, of mobility and of authorization to move. 

Today, it is very difficult to transport a working environment between two 
computers, for example, between a laptop and a desktop, or between home and 
work computers. The working environment might consist of data that has to 
be copied, and of running programs in various stages of active or suspended 
communication with the network that have to be shut down and restarted. Why 
can’t we just say “move this (part of the) environment to that computer” and 
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carry on? When on a trip, why couldn’t we transfer a piece of the desktop 
environment (for example, a forgotten open document along with its editor) to 
the laptop over a phone line? We would like to discover techniques to achieve all 
this easily and reliably. 

With these motivations, we adopt a paradigm of mobility where compu- 
tational ambients are hierarchically structured, where agents are confined to 
ambients and where ambients move under the control of agents. A novelty of 
this approach is in allowing the movement of self-contained nested environments 
that include data and live computation, as opposed to the more common tech- 
niques that move single agents or individual objects. Our goal is to make mobile 
computation scale-up to widely distributed, intermittently connected and well 
administered computational environments. 

10.1 Ambients 

An ambient, in the sense in which we are going to use this word, has the following 
main characteristics: 

— An ambient is a bounded place where computation happens. The interest- 
ing property here is the existence of a boundary around an ambient. If we 
want to move computations easily we must be able to determine what should 
move; a boundary determines what is inside and what is outside an ambient. 
Examples of ambients, in this sense, are: a web page (bounded by a file), 
a virtual address space (bounded by an addressing range), a Unix file sys- 
tem (bounded within a physical volume), a single data object (bounded by 
“self”) and a laptop (bounded by its case and data ports). Non-examples are: 
threads (where the boundary of what is “reachable” is difficult to determine) 
and logically related collections of objects. We can already see that a bound- 
ary implies some flexible addressing scheme that can denote entities across 
the boundary; examples are symbolic links. Uniform Resource Locators and 
Remote Procedure Call proxies. Flexible addressing is what enables, or at 
least facilitates, mobility. It is also, of course, a cause of problems when the 
addressing links are “broken” . 

— An ambient is something that can be nested within other ambients. As we 
discussed, administrative domains are (often) organized hierarchically. If we 
want to move a running application from work to home, the application 
must be removed from an enclosing (work) ambient and inserted in a differ- 
ent enclosing (home) ambient. A laptop may need a removal pass to leave 
a workplace, and a government pass to leave or enter a country. 

— An ambient is something that can be moved as a whole. If we reconnect a lap- 
top to a different network, all the address spaces and file systems within it 
move accordingly and automatically. If we move an agent from one computer 
to another, its local data should move accordingly and automatically. 
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More precisely, we investigate ambients that have the following structure: 

— Each ambient has a name. The name of an ambient is used to control access 
(entry, exit, communication, etc.). In a realistic situation the true name of an 
ambient would be guarded very closely, and only specific capabilities would 
be handed out about how to use the name. In our examples we are usually 
more liberal in the handling of names, for the sake of simplicity. 

— Each ambient has a collection of local agents (also known as threads, pro- 
cesses, etc.). These are the computations that run directly within the ambi- 
ent and, in a sense, control the ambient. For example, they can instruct the 
ambient to move. 

— Each ambient has a collection of subambients. Each subambient has its own 
name, agents, subambients, etc. 

10.2 Technical Context: Systems 

Many software systems have explored and are exploring notions of mobility. 

Among these are: 

— Obliq [Car95]. The Obliq project attacked the problems of distribution and 
mobility for intranet computing. It was carried out largely before the Web 
became popular. Within its scope, Obliq works quite well, but is not really 
suitable for computation and mobility over the Web, just like most other 
distributed paradigms developed in pre-Web days. 

— Telescript [Whi96]. Our ambient model is partially inspired by Telescript, 
but is almost dual to it. In Telescript, agents move whereas places stay put. 
Ambients, instead, move whereas agents are confined to ambients. A Tele- 
script agent, however, is itself a little ambient, since it contains a “suitcase” 
of data. Some nesting of places is allowed in Telescript. 

— Java [GJS96]. Java provides a working paradigm for mobile computation, as 
well as a huge amount of available and expected infrastructure on which to 
base more ambitious mobility efforts. 

— Linda [CG89]. Linda is a “coordination language” where multiple processes 
interact in a common space (called a tuple space) by dropping and pick- 
ing up tokens asynchronously. Distributed versions of Linda exist that use 
multiple tuple spaces and allow remote operations over those. A dialect of 
Linda [GGZ95] allows nested tuple spaces, but not mobility of the tuple 
spaces. 

10.3 Technical Context: Formalisms 

Many existing calculi have provided inspiration for our work. In particular: 

— Enrichments of the pi calculus with locations have been studied, with the 
aim of capturing notions of distributed computation. In the simplest form, 
a flat space of locations is added, and operations can be indexed by the loca- 
tion where they are executed. Riely and Hennessy [RH98] and Sewell [Sew98] 
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propose versions of the pi calculus extended with primitives to allow com- 
putations to migrate between named locations. The emphasis in this work 
is on developing type systems for mobile computation based on existing 
type systems for the pi calculus. Riely and Hennessy’s type system regulates 
the usage of channel names according to permissions represented by types. 
Sewell’s type system differentiates between local and remote channels for the 
sake of efficient implementation of communication. 

— The join calculus [FG96] is a reformulation of the pi calculus with a more 
explicit notion of places of interaction; this greatly helps in building dis- 
tributed implementations of channel mechanisms. The distributed join cal- 
culus [FGL+96] adds a notion of named locations, with essentially the same 
aims as ours, and a notion of distributed failure. Locations in the distributed 
join calculus form a tree, and subtrees can migrate from one part of the tree 
to another. A significant difference from our ambients is that movement may 
happen directly from any active location to any other known location. 

— LLinda [NFP97] is a formalization of Linda using process calculi techniques. 
As in distributed versions of Linda, LLinda has multiple distributed tuple 
spaces. Multiple tuple spaces are very similar in spirit to multiple ambients, 
but Linda’s tuple spaces do not nest, and there are no restrictions about 
accessing a tuple space from any other tuple space. 

— A growing body of literature is concentrating on the idea of adding dis- 
crete locations to a process calculus and considering failure of those loca- 
tions [Ania97, FGL+96]. This approach aims to model traditional distributed 
environments, along with algorithms that tolerate node failures. However, 
on the internet, node failure is almost irrelevant compared with inability 
to reach nodes. Web servers do not often fail forever, but they frequently 
disappear from sight because of network or node overload, and then they 
come back. Sometimes they come back in a different place, for example, 
when a Web site changes its internet Service Provider. Moreover, inability 
to reach a Web site only implies that a certain path is unavailable; it im- 
plies neither failure of that site nor global imreachability. In this sense, an 
observed node failure cannot simply be associated with the node itself, but 
instead is a property of the whole network, a property that changes over 
time. Our notion of locality is induced by a non-trivial and dynamic topol- 
ogy of locations. Failure is only represented, in a weak but realistic sense, as 
becoming forever unreachable. 

10.4 Summary of Our Approach 

With respect to previous work on process calculi, we can characterize the main 
differences in the ambient calculus approach as follows. In each of the following 
points, our emphasis is on boundaries and their effect on computation. The 
existence of separate locations is represented by a topology of boundaries. This 
topology induces an abstract notion of distance between locations. Locations 
are not uniformly accessible, and are not identified by globally unique names. 
Process mobility is represented as crossing of boundaries. In particular, process 
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mobility is not represented as communication of processes or process names over 
channels. Security is represented as the ability or inability to cross boundaries. 
In particular, security is not directly represented by cryptographic primitives or 
access control lists. Interaction between processes is by shared location within 
a common boundary. In particular, interaction cannot happen without proper 
consideration of boundaries and their topology. 



11 A Polyadic Ambient Calculus 

The ambient calculus of this section is a slight extension of the original untyped 
ambient calculus [CGOOb]. In that calculus, communication is based on the ex- 
change of single values. Here we extend the calculus with communication based 
on tuples of values (polyadic communication), since this simple extension greatly 
facilitates the task of providing an expressive type system. We also add objective 
moves and we annotate bound variables with type information. 

The ambient calculus is a derivative of the pi calculus. Four of its process 
constructions (restriction, inactivity, composition, and replication) are exactly 
as in the pi calculus. To these we add ambients, capabilities, and a simple form of 
communication. We briefly discuss these constructions; see [CGOOb] for a more 
detailed introduction. 

The restriction operator, {vn\W)P, creates a new (unique) name n of type W 
within a scope P. The new name can be used to name ambients and to operate on 
ambients by name. The inactive process, 0, does nothing. Parallel composition 
is denoted by a binary operator, P \ Q, that is commutative and associative. 
As in the pi calculus, replication is a technically convenient way of representing 
iteration and recursion: the process \P denotes the unbounded replication of the 
process P and is equivalent to P \ IP. 

An ambient is written M[P], where M is the name of the ambient, and P is 
the process running inside the ambient. 

The process M.P executes an action regulated by the capability M, and 
then continues as the process P. We consider three kinds of capabilities: one 
for entering an ambient, one for exiting an ambient, and one for opening up an 
ambient. (The latter requires special care in the type system.) Gapabilities are 
obtained from names; given a name n, the capability inn allows entry into n, the 
capability out n allows exit out of n and the capability open n allows the opening 
of n. Implicitly, the possession of one or all of these capabilities is insufficient 
to reconstruct the original name n from which they were extracted. Gapabilities 
can also be composed into paths, M.M', with e for the empty path. 

Gommunication is asynchronous and local to an ambient. It is similar to chan- 
nel communication in the pi calculus, except that the channel has no name: the 
surrounding ambient provides the context where the communication happens. 
The process (Mi,...,Mfc) represents the output of a tuple of values, with no 
continuation. The process . . . ,Xk-Wk).P represents the input of a tuple 

of values, whose components are bound to x\, . . . ,Xk, with continuation P. 
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Communication is used to exchange both names and capabilities, which share 
the same syntactic class M of messages. The first task of our type system is to 
distinguish the messages that are names from the messages that are capabilities, 
so that each is guaranteed to be used in an appropriate context. In general, the 
type system might distinguish other kinds of expressions, such as integer and 
boolean expressions, but we do not include those in our basic calculus. 

The process go N .M[P] moves the ambient M[P] as specified by the N capa- 
bility, and has M[P] as its continuation. It is called an objective move since the 
ambient M[P] is moved from the outside, while a movement caused by a process 
N.P which runs inside an ambient is called a subjective move. In the untyped 
calculus, we can define an objective move go N.M[P] to be short for the process 
{iyk)k[N.M[out k.P]] where k is not free in P. As we will show in Section 16.2, 
a primitive typing rule for objective moves allows more refined typings than are 
possible with only subjective moves. 



Messages and Processes: 



M ::= 


message 


n 


name 


in M 


can enter into M 


out M 


can exit out of M 


open M 


can open M 


e 


null 


M.M' 


path 


P,Q,R::= 


process 


{vn\W)P 


restriction 


0 


inactivity 


P\Q 


composition 


IP 


replication 


M[P] 


ambient 


M.P 


action 


{xv.Wi,...,Xk-.Wk).P 


input action 


(Mi,...,Mfe) 


output action 


go N.M[P] 


objective move 


The following table displays the main reduction rules of the calculus (the full 
set is presented in Section 14). The notation P{x\^Mi} ■ ■ ■ {xk^M^} in rule 
(Red I/O) denotes the outcome of a capture-avoiding simultaneous substitution 


of message Mi for each free 
process P, for i e l..k. 


occurrence of the corresponding name Xi in the 


Reduction: 





n[in m.P \ Q] \ m[R\ m[n[P | Q] | i?] (Red In) 

m[n[out m.P | Q] | i?] — > n[P \ Q] \ m[R] (Red Out) 
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open n.P \ n[Q] — > P | Q 

I {xi-.Wi,...,Xk-.Wk).P^ 
P{xi^Mi} ■ ■ ■ {xk^Mk} 
go{in m.N).n[P] \ m[Q\ m[go N.n[P] \ Q] 
m[go{out m.N).n[P] \ Q] ^ go N.n[P] \ m[Q] 



(Red Open) 
(Red I/O) 

(Red Go In) 
(Red Go Out) 



We will use the following syntactic conventions: 

— parentheses may be used for precedence 

— {vn:W)P I Q is read {{vn\W)P) \ Q 

— !P I Q is read (!P) | Q 

— M.P I Q is read {M.P) \ Q 

— . . .,nk-.Wk)-P \ Q is read {{nr.Wi, . . .,nk--Wk).P) \ Q 

— n[] Jn[0] 

— M = M.O (where appropriate) 

As an example, consider the following process: 

a[p[out a.in b.{c)]] \ b[open p.{x).x\'^ 

Intuitively, this example represents a packet named p being sent from a ma- 
chine a to a machine b. The process p[out a.in b.{c)] represents the packet, as 
a subambient of ambient a. The name of the packet ambient is p, and its interior 
is the process out a.in b.{c). This process consists of three sequential actions: 
exercise the capability out a, exercise the capability in b, and then output the 
name c. The effect of the two capabilities on the enclosing ambient p is to move 
p out of a and into b (rules (Red Out), (Red In)), to reach the state: 

a[] I b[p[{c)] I openp.{x).x[]] 

In this state, the interior of a is empty but the interior of b consists of 
two running processes, the subambient p[(c)] and the process open p.{x).x'^. 
This process is attempting to exercise the open p capability. Previously it was 
blocked. Now that the p ambient is present, the capability’s effect is to dissolve 
the ambient’s boundary; hence, the interior of b becomes the process (c) | (a:).a:[] 
(Red Open). This is a composition of an output (c) with an input (a;).a;[]. The 
input consumes the output, leaving c[] as the interior of b (Red I/O). Hence, the 
final state of the whole example is a[] | 6[c[]]. 

As an example of objective moves, consider the following variation of the 
previous process: 



a[go(out a.in b).p[{c)]] \ b[open p.{x).x\\] 

In this case, the ambient p[(c)] is moved from the outside, out of a and into b 
(rules (Red Go Out), (Red Go In)), to reach the same state that was reached in 
the previous version after the (Red Out), (Red In) subjective moves: 



a[] I b[p[{c)] I openp.{x).x[]] 
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See the original paper on the ambient calculus [CGOOb] for many more ex- 
amples, including locks, data structures such as booleans and numerals, Turing 
Machines, routable packets and active networks, and encodings of the lambda 
calculus and the pi calculus. 



12 Types for the Ambient Calculus 

Type systems are, today, a widely applied technique allowing programmers to de- 
scribe the key properties of their code, and to have these properties mechanically 
and efficiently checked. Mobile code makes types, and machine-checkable prop- 
erties in general, useful for security reasons too, as has been demonstrated by 
the checking performed on Java applets [LY97] and on other mobile code [GSOl]. 

In standard languages, the key invariants that are maintained by type systems 
have mainly to do with the contents of variables and with the interfaces of 
functions, procedures, or methods. In the ambient calculus, the basic properties 
of a piece of code are those related to its mobility, to the possibility of opening 
an ambient and exposing its content, and to the type of data which may be 
exchanged inside an ambient. To understand how groups arise in this context, 
consider a typical static property we may want to express in a type system for 
the ambient calculus; informally: 

The ambient named n can enter the ambient named m. 

This could be expressed as a typing n : CanEnter{m) stating that n is a member 
of the collection CanEnter(m) of names that can enter m. However, this would 
bring us straight into the domain of dependent types [GH88], since the type 
CanEnter{m) depends on the name m. Instead, we introduce type-level groups 
of names, G, iJ, and restate our property as: 

The name m belongs to group G. 

The ambient named n can enter any ambient of group G. 

This idea leads to typings of the form: m : G, n : CanEnter{G) which are 
akin to standard typings such as x : Int, y : Channel{Int) . 

To appreciate the relevance of groups in the description of distributed sys- 
tems, consider a programmer coding a typical distributed system composed of 
nodes and mobile threads moving from one node to another, and where threads 
communicate by sending input and output packets through typed channels. In 
these notes, we define a type system where a programmer can: 

— define groups such as Node, Thread, Channel, and Packet, which match the 
system structure; 

— declare properties such as: this ambient is a Thread and it may only cross 
ambients which are Nodes; this ambient is a Packet and can enter Channels; 
this ambient is a Channel of type T , and it cannot move or be opened, but 
it may open Packets containing data of type T ; this ambient is a Node and 
it cannot move or be opened; 
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— have the system statically verify all these properties. 

Our groups are similar to sorts used in typed versions of the pi calcu- 
lus [Mil99], but we introduce an operation, {vG)P, for creating a new group G, 
which can be used within the process P. 

The binders for new groups, {vG), can float outward as long as this adjust- 
ment, extrusion, does not introduce name clashes. Because of extrusion, group 
binders do not impede the mobility of ambients that are enclosed in the initial 
scope of fresh groups but later move away. On the other hand, even though ex- 
trusion enlarges scopes, simple scoping restrictions in the typing rules prevent 
names belonging to a fresh group from ever being received by a process which 
has been defined outside the initial scope of the group. 

Therefore, we obtain a flexible way of protecting the propagation of names. 
This is to be contrasted with the situation in most untyped nominal calculi, 
where names can (intentionally, accidentally, or maliciously) be extruded arbi- 
trarily far, by the automatic and unrestricted application of extrusion rules, and 
communicated to other parties. 



13 Introduction to Exchange Types 

An ambient is a place where processes can exchange messages and where other 
ambients can enter and exit. We introduce here a type system which regulates 
communication, while mobility will be tackled in the following sections. This 
system generalizes the one presented in [CG99] by allowing the partitioning of 
ambients into groups. 

13.1 Topics of Conversation 

Within an ambient, multiple processes can freely execute input and output ac- 
tions. Since the messages are undirected, it is easily possible for a process to 
utter a message that is not appropriate for some receiver. The main idea of the 
exchange type system is to keep track of the topic of conversation that is per- 
mitted within a given ambient, so that talkers and listeners can be certain of 
exchanging appropriate messages. 

The range of topics is described in the following table by message types, W, 
and exchange types, T. The message types are G[T], the type of names of am- 
bients which belong to the group G and that allow exchanges of type T, and 
Cap [T], the type of capabilities that when used may cause the unleashing of T ex- 
changes (as a consequence of opening ambients that exchange T). The exchange 
types are Shh, the absence of exchanges, and Wi x . . . x Wk, the exchange of 
a tuple of messages with elements of the respective message types. For k = 0, 
the empty tuple type is called 1; it allows the exchange of empty tuples, that is, 
it allows pure synchronization. The case k = 1 allows any message type to be an 
exchange type. 
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Types: 

W ::= 

GIT] 

Cap[T] 

S,T:-.= 

Shh 

WiX---xWk 



message type 

name in group G for ambients allowing T exchanges 
capability unleashing T exchanges 
exchange type 
no exchange 

tuple exchange (1 is the null product) 



For example, in a scope where the Agent and Place groups have been defined, 
we can express the following types: 

— An ambient of the Agent group where no exchange is allowed (a quiet Agent): 
Agent[Shh] 

— A harmless capability: Cap[Shh] 

— A Place where names of quiet Agents may be exchanged: 

Place [Agent [ 5 / 1 / 1 ]] 

— A Place where harmless capabilities may be exchanged: 

Place[Cap[Shh\\ 

— A capability that may unleash the exchange of names of quiet Agents: 

Cap[Agent[Shh]] 



13.2 Intuitions 

Before presenting the formal type rules (in Section 14), we discuss the intuitions 
that lead to them. 



Typing of Processes If a message M has message type W, then (M) is a pro- 
cess that outputs (exchanges) W messages. Therefore, we will have a rule stating 
that: 



M : W implies (M) : W 

If P is a process that may exchange W messages, then (x:W).P is also a pro- 
cess that may exchange W messages. Therefore: 

P : W implies (x:W).P : W 

The process 0 exchanges nothing, so it naturally has exchange type Shh. 
However, we may also consider 0 as a process that may exchange any type. 
This is useful when we need to place 0 in a context that is already expected to 
exchange some type: 
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0 : T for any T 

Alternatively, we may add a subtype relation among types, give 0 a minimal 
type, and add a rule which allows processes with a type to appear where processes 
with a supertype are required [ZimOO]. We reject this approach here only because 
we want to explore the ideas of group-based exchange and mobility types in the 
simplest possible setting. 

If P and Q are processes that may exchange T, then P | Q is also such 
a process. Similarly for IP: 

P :T,Q:T implies P\Q :T 
P : T implies !P : T 

Therefore, by keeping track of the exchange type of a process, T-inputs and 
T-outputs are tracked so that they match correctly when placed in parallel. 

Typing of Ambients An ambient n[P] is a process that exchanges nothing at 
the current level, so, like 0, it can be placed in parallel with any process, hence 
we allow it to have any exchange type: 

n[P] : T for any T 

There needs to be, however, a connection between the type of n and the type 
of P. We give to each ambient name n a type G[T], meaning that n belongs 
to the group G and that only T exchanges are allowed in any ambient of that 
name. Hence, a process P can be placed inside an ambient with that name n 
only if the type of P is P: 

n : G[T],P : T implies n[P] is well- formed (and can have any type) 

By tagging the name of an ambient with the type of exchanges, we know 
what kind of exchanges to expect in any ambient we enter. Moreover, we can 
tell what happens when we open an ambient of a given name. 

Typing of Open Tracking the type of I/O exchanges is not enough by itself. 
We also need to worry about open, which might open an ambient and unleash 
its exchanges inside the surrounding ambient. 

If ambients named n permit T exchanges, then the capability open n may 
unleash those T exchanges. We then say that openn has a capability type Cap\T], 
meaning that it may unleash T exchanges when used: 

n : G\T] implies open n : Cap\T] 

As a consequence, any process that uses a Cap\T] must be a process that is al- 
ready willing to participate in exchanges of type T, because further T exchanges 
may be unleashed: 



M : Cap[T],P : T implies M.P : T 
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Typing of In and Out The exercise of an in or out capability cannot cause any 
exchange, hence such capabilities can be prepended to any process. Following the 
same pattern we used with 0 and ambients, the silent nature of these capabilities 
is formalized by allowing them to acquire any capability type: 

in n : Cap[T] for any T 
out n : Cap[T] for any T 



Groups Groups are used in the exchange system to specify which kinds of 
messages can be exchanged inside an ambient. We add a process construct to 
create a new group G with scope P: 



{vG)P 

The type rule of this construct specifies that the process P should have an 
exchange type T that does not contain G. Then, {vG)P can be given type T as 
well. That is, G is never be allowed to “escape” into the type of {vG)P\ 

P : T, G does not occur in T implies {vG)P : T 



14 Typed Ambient Calculus 

We are now ready for a formal presentation of the typed calculus which has been 
informally introduced in the previous section. We first present its syntax, then 
its typing rules, and finally a subject reduction theorem, which states that types 
are preserved during computation. 



14.1 Types and Processes 

We first recall the definition of the types of the exchange system. 



Types: 

W ::= 

G[T] 

Cap[T] 

S,T:-.= 

Shh 

Wi X • • • X Wfe 



message type 

name in group G for ambients allowing T exchanges 
capability unleashing T exchanges 
exchange type 
no exchange 

tuple exchange (1 is the null product) 



Messages and processes are the same as in the untyped calculus of Section 11. 

Messages and Processes: 

M ::= 



n 



message 

name 
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in M 


can enter into M 


out M 


can exit out of M 


open M 


can open M 


e 


null 


M.M' 


path 


Q,R--= 


process 


{uG)P 


group creation 


{vn:W)P 


restriction 


0 


inactivity 


P\Q 


composition 


IP 


replication 


M[P] 


ambient 


M.P 


action 


{xi:Wi,...,Xk:Wk).P 


input action 




output action 


go N.M[P] 


objective move 



We identify processes up to consistent renaming of bound names and groups. 
In the processes (vG)P and {vn:W)P, the group G and the name n, respectively, 
are bound, with scope P. In the process . . . ,Xk'Wk)-P^ the names x\, 

. . . , Xk are bound, with scope P. 

The following table defines the free names of processes and messages, and 
the free groups of processes and types. 



Free Names and Free Groups: 

fn{{,^G)P)=fn{P) 

H(un:W)P) = HP) - {n} 
fn{0) = 0 

HP \ Q) = HP) a HQ) 
H'-P)=Hp) 

HM[p]) = HM)uHp) 
Hm.p) = HM)uHp) 
fn{{xi:Wi ,. . .,Xk-.Wk).P) = fn{P) 

fy((Mi,...,Mfe)) = fy(Mi)U---U 
Hgo N.M[P]) = HH U fn{M) u 

fgHG)P) ^ fg{P) - {G} 
fgHn:W)P)^fg{W)Ufg{P) 
fg{0) ^ 0 

fg{P\Q)=fgiP)^fgiQ) 

fg{\P)=fg{P) 



fn{n) = {n} 
fn{inM) = fn{M) 
fn{outM) = fn{M) 
fn{open M) = fn{M) 

HQ = 0 

fn{M.N) = fn{M) U /n(N) 

- {xi,...,a;fe} 

^n{Mk) 

fn{P) 

fg{G[T])^{G}Ufg{T) 
fg{Cap[T\) ^ fg{T) 
fg(Shh) ^ 0 
fg{Wi x---xWk) = 
fg{Wi)U---Ufg{Wk) 
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fg{M[P]) = fg{P) 
fg{M.P)^fg{P) 

fgiixi-.Wu. ■ . ,Xk:Wk).P) = fg{Wi) U • • ■ U fg{Wk) U fg{P) 
fg{{M,,...,Mk)) = 0 

fgjgo N.M[P]) ^ fgjP) 



The following tables describe the operational semantics of the calculus. The 
type annotations present in the syntax do not play a role in reduction; they are 
simply carried along by the reductions. 

Processes are identified up to an equivalence relation, =, called structural 
congruence. As in the pi calculus, this relation provides a way of rearranging 
processes so that interacting parts can be brought together. Then, a reduction 
relation, acts on the interacting parts to produce computation steps. The core 
of the calculus is given by the reduction rules (Red In), (Red Out), (Red Go In), 
(Red Go Out), and (Red Open), for mobility, and (Red I/O), for communication. 

The rules of structural congruence are similar to the rules for the pi calculus. 
The rules (Struct GRes . . . ) describe the extrusion behaviour of the (t^G) binders. 
Note that {vG) extrudes exactly as {vn) does, hence it does not pose any dynamic 
restriction on the movement of ambients or messages. 



Reduction: 



n[in m.P Q] m[R] m[n[P Q] i?] 




(Red In) 


m[n[out m.P | Q] | i?] — > n[P \ Q] \ m[R] 




(Red Out) 


open n.P \ n[Q] ^ P \ Q 




(Red Open) 


(Mi,...,Mfe) 1 {xi-.Wi,...,Xk:Wk).P ^ 




(Red I/O) 


P{xi^Mi} ■ ■ ■ {xk^Mk} 






go{in m.N).n[P] \ m[Q] —>■ m[go N.n[P] \ 


Q] 


(Red Go In) 


m[go{out m.N).n[P] Q] — *■ <?o N.n[P] m[Q] 


(Red Go Out) 


p ^ Q ^ p \ Q \ R 




(Red Par) 


P ^ Q ^ {vn\W)P — > {vn\W)Q 




(Red Res) 


P^Q^ {vG)P {vG)Q 




(Red GRes) 


P ^ Q ^ n[P] n[Q] 




(Red Amb) 


P' = P,P ^ Q,Q = Q' ^ P' ^ Q' 




(Red =) 



Structural Congruence: 



'p = P 


(Struct Refi) 


Q=P^P=Q 


(Struct Symm) 


P = Q,Q = R^P = R 


(Struct Trans) 


P = Q^ {vn-.W)P = {vn:W)Q 


(Struct Res) 


P = Q^ (lyG)P = (lyG)Q 


(Struct GRes) 


P = Q^P\R=Q\R 


(Struct Par) 
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P = Q^\P=\Q 


(Struct Repl) 


P = Q^ M[P] = M[Q] 


(Struct Amb) 


P = Q^ M.P = M.Q 


(Struct Action) 


P = Q^ 


(Struct Input) 


{xr.Wi,. . .,xu-.Wk).P = {xi-.Wi, . . -,Xk:Wk).Q 
P = Q^ go N.M[P] = go N.M[Q] 


(Struct Go) 


P\Q = Q\P 


(Struct Par Comm) 


{P\Q)\R = P\{Q\R) 


(Struct Par Assoc) 


\P = P\ \P 


(Struct Repl Par) 


ni ^ U2 ^ 


(Struct Res Res) 


{i/ni:Wi){h'n2'.W2)P = {iyn2'W2){i^ni:Wi)P 
n ^ fn{P) => {iyn:W){P \ Q) = P \ lvn:W)Q 


(Struct Res Par) 


n ^ m ^ {vn:W)m[P] = m[{vn:W)P] 


(Struct Res Amb) 


{iyGi){j^G2)P={iyG2){i^Gi)P 


(Struct GRes GRes) 


G ^ fg{W) => {vG){vn:W)P = {vn:W){vG)P 


(Struct GRes Res) 


Gifg{P)^{uG){P\Q)=P\{vG)Q 


(Struct GRes Par) 


{vG)m[P] = m[{vG)P] 


(Struct GRes Amb) 


P\Q = P 


(Struct Zero Par) 


{vn-.W){) = 0 


(Struct Zero Res) 


(j/G)0 = 0 


(Struct Zero GRes) 


!0 = 0 


(Struct Zero Repl) 


e.P = P 


(Struct e) 


(M.M').P = M.M'.P 


(Struct .) 


go e.M[P] = M[P] 


(Struct Go e) 



14.2 Typing Rules 

In the tables below, we introduce typing environments, E, the five basic judg- 
ments, and the typing rules. 

Environments, E, and the Domain, dom{E), of an Environment: 

E ::= 0 I E, G I E,n:W environment 

dom{0) = 0 

dom{E, G) = dom{E) U {G} 
dom{E,n:W) = dom{E) U {n\ 
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Judgments: 


Eho 


good environment 


Eh VP 


good message type VP 


EhT 


good exchange type T 


Eh M : VP 


good message M of message type VP 


Eh P:T 


good process P with exchange type T 



Good Environments: 



(Env 0) 


(Env n) 


(Env G) 




E h VP n ^ dom{E) 


Eho G ^ dom{E) 


0 h 0 


E,n:W h 0 


E,G ho 



Good Types: 



(Type Amb) 

G e dom{E) EhT 


(Type Cap) 
EhT 


(Type Shh) 
Eho 


(Type Prod) 
E h VPi • • • 


EhVPfe 


E h G[T] 


Eh Cap[T] 


Eh Shh 


E h VPi X • 


••xVPfc 


Good Messages: 



(Exp n) 

E',n:W,E" h o 


(Exp .) 
Eh M 


: Cap[T] 


Eh M' : Cap[T] 


E',n:W,E” hn:W 




E h M.M' 


' : Cap[T] 



(Exp e) 

E h Cap[T] 
Eh e : Cap[T] 



(Exp In) 

E h n : G[S] E^T 
E \- in n : Cap[T] 



(Exp Out) 

E h n : G[E] E h E 
E h out n : Cap[T] 



(Exp Open) 

E h n : G[T] 

E h open n : Cap\T] 



Good Processes: 

(Proc Action) (Proc Amb) 

E^M-.Cap[T] EhP:T E^ M : G[E] E h E : g E h E 
E h M.P -.T Eh M[P] : T 



(Proc Res) 

E,n:G[S] h E : T 
Eh {vn:G[S])P : T 



(Proc GRes) 

E,GhP:T GjfgiT) 
E h {vG)P : T 



(Proc Zero) (Proc Par) (Proc Repl) 

EhT EhP-.T EhQ-.T E h P : T 



Eh 0 : T 



E h E I Q : T 



E h !E : E 
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(Proc Input) 

E,ni:Wi,...,nk:Wk^ P : Wi x ■ ■ ■ X Wk 
E h {m-.Wi, . . . ,nk:Wk).P : Wi x ■ ■ ■ x Wk 

(Proc Output) 

E'r Mi: Wi ■■■ E'r Mk'.Wk 
Eh (Mi,...,Mk) :WiX---xWk 

(Proc Go) 

EhN:Cap[S'] E h M : G[S] E h P : S EhT 
Eh go N.M[P] : T 



14.3 Subject Reduction 

We obtain a standard subject reduction result. A subtle point, though, is the 
need to account for the appearance of new groups (Gi, . . . , Gfe, below) during 
reduction. This is because reduction is defined up to structural congruence, and 
structural congruence does not preserve the set of free groups of a process. The 
culprit is the rule {i'n:W)0 = 0, in which groups free in W are not free in 0. 

Lemma 1 (Subject Congruence). If E h P : T and P = Q then there 
are G\, . . . , Gk such that Gi, . . . , Gfc, E h Q : T. 

Theorem 1 (Subject Reduction). If E h P : T and P ^ Q then there 
are G\, . . . , Gk such that G\, . . . ,Gk,E h Q : T . 

Subject reduction specifies that, if P is well- typed, it will only reduce to 
well-typed terms. This fact has some practical consequences: 

— P will never reduce to meaningless processes allowed by the syntax like 
(in n)[P]] 

— no process deriving from P will contain an ambient where a process attempts 
an input or output operation which does not match the ambient type. 

Subject reduction has also interesting and subtle connections with secrecy of 
names. Consider a well-typed process {{i/G).P) \ O, where O is a type-checked 
“opponent”, and a name n is declared inside P with a type G[T]. Although 
(j^G) can be extruded arbitrarily far, according to the extrusion rules, no process 
which derives from the opponent O will ever be able to read n through an input 
{x:W).Q. Any process (n) | {x:W).Q which derives from {{vG).P) \ O is well- 
typed, hence W = G[T], but the opponent was not, by assumption, in the initial 
scope of G, and therefore cannot even mention the type G[T]. Therefore, we 
can guarantee that names of group G can never be communicated to processes 
outside of the initial scope of G, simply because those processes cannot name G 
to receive the message. 

This situation is in sharp contrast with ordinary name restriction, where 
a name that is initially held secret (e.g., a key) may accidentally be given away 
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and misused (e.g., to decrypt current or old messages). This is because scoping of 
names can be extruded too far, inadvertently. Scoping of groups can be extruded 
as well, but still offers protection against accidental or even malicious leakage. 

Of course, we would have even stronger protection if we did not allow (i^G) 
binders to extrude at all. But this would be too rigid. Since (vG) binders can be 
extruded, they do not impede the mobility of ambients that carry secrets. They 
just prevent those ambients from giving the secrets away. Consider the following 
example of travelling agents sharing secrets. 

: G[Shh]){iyk” : G[Shh]){ 
k'[out a. in b.out b.in c] | 
k''[out a. in c.in fc']) 

]\b[]\ c[] 

Within an ambient a, two agents share a secret group G and two names 
k' and k" belonging to that group. The two agents adopt the names k' and k" 
as their respective names, knowing that those names cannot be leaked even by 
themselves. This way, as they travel, nobody else can interfere with them. If 
somebody interferes with them, or demonstrates knowledge of the names k' or 
A:", the agents know that the other party must be (a descendant of) the other 
agent. In this example, the first agent travels to ambient b and then to c, and 
the second agent goes to ambient c directly. The scope extrusion rules for groups 
and names allow this to happen. Inside c, out of the initial scope of (I'G), the 
second agent then interacts with the first by entering it. It can do so because it 
still holds the shared secret k' . 

We omit the proof that structural congruence preserves typing, but we com- 
ment here on the crucial case: the preservation of typing by the extrusion rule 
(Struct GRes Amb). For a well-typed P, {vG)P is well-typed if and only if 
P does not communicate a tuple which names G in its type (rule (Proc GRes)): 
(lyG) must not “see” G-typed names communicated at its own level. This intu- 
ition suggests that, referring to the following table, P' should be typeable ((j^G) 
cannot “see” the output (n)) while P" should be not ((n) is at the same level 
as {vG)). However, the two processes are equivalent, modulo extrusion of (j^G) 
(rule (Struct GRes Amb)): 

P' = {i^G)m[{i'n:G[Shh]) (n)] 

P" = m[(i>G)lh'n:G[Shh]){n)] 

We go through the example step by step, to solve the apparent paradox. First 
consider the term 



{i'G){i'n:G[Shh]) (n) 

This term cannot be typed, because G attempts to escape the scope of 
(h'G){vn:G[Shh]) as the type of the message n. An attempted typing derivation 
fails at the last step below: 
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^ G,n:G[Shh]\-n-.G[Shh] 

^ G,n:G[Shh]^ {n) : G[Shh] 

^ G h {iyn:G[Shh]){n) : G[Shh] 

^ h {iyG){vn-.G[Shh]){n) : G[Shh] (because G G fn{G[Shh])) 
Similarly, the term 

{vm:W)rn[{i'G){vn-.G[Shh]){n)] 

cannot be typed, because it contains the previous untypeable term. But now 
consider the following term, which is equivalent to the one above up to structural 
congruence, by extrusion of {i^G) across an ambient boundary: 

{i/m:W){iyG)m[{i/n:G[Shh]){n)] 

This term might appear typeable (contradicting the subject congruence prop- 
erty) because the message {n):G[Shh] is confined to the ambient to, and m[. . .] 
can be given an arbitrary type, e.g., Shh, which does not contain G. Therefore 
(i/G) would not “see” any occurrence of G escaping from its scope. However, con- 
sider the type of to in this term. It must have the form H[T], where H is some 
group, and T is the type of messages exchanged inside to. But that’s G[Shh]. So 
we would have 

{vm:H[G[Shh]]){i/G)m[{vn:G[Shh]){n)] 

which is not typeable because the first occurrence of G is out of scope. 

This example tells us why {vG) intrusion (floating inwards) into ambi- 
ents is not going to break good typing: {I'G) cannot enter the scope of the 
(um'.W) restriction which creates the name m of an ambient where messages 
with a G-named type are exchanged. This prevents (i^G) from entering such 
ambients. 

Indeed, the following variation (not equivalent to the previous one) is ty- 
peable, but (i^G) cannot intrude any more: 

{i/G){i'm:H[G[Shh]])m[{i'n:G[Shh]){n)] 

15 Opening Control 

Ambient opening is a prerequisite for any communication to happen between 
processes which did not originate in the same ambient. On the other hand, 
opening is one of the most delicate operations in the ambient calculus, since the 
contents of the guest spill inside the host, with two different classes of possible 
consequences: 

— the content of the guest acquires the possibility of performing communica- 
tions inside the hosts, and of moving the host around; 
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— the host is now able to examine the content of the guest, mainly in terms of 
receiving messages sent by the processes inside the guest, and of opening its 
subambients. 

For these reasons, a type system for ambients should support a careful control 
of the usage of the open capability. 

15.1 The System 

In this section, we enrich the ambient types, G\T], and the capability types, 
Cap\T], of the previous type system to control usage of the open capability. 

To control the opening of ambients, we formalize the constraint that the name 
of any ambient opened by a process is in one of the groups Gi , . . . , Gfc , but in no 
others. To do so, we add an attribute °{Gi, . . . , Gfc} to ambient types, which now 
take the form G[°{Gi, . . . , Gfc}, T], A name of this type is in group G, and names 
ambients within which processes may exchange messages of type T and may only 
open ambients in the groups Gi, . . . , Gfc. We need to add the same attribute to 
capability types, which now take the form Gap[°{Gi, . . . , Gfc}, T], Exercising a 
capability of this type may unleash exchanges of type T and openings of ambi- 
ents in groups Gi, . . . , Gfc. The typing judgment for processes acquires the form 
E \- P : °{Gi, . . . , Gfc}, T. The pair °{Gi, . . . , Gfc}, T constrains both the open- 
ing effects (what ambients the process opens) and the exchange effects (what 
messages the process exchanges). We call such a pair an effect, and introduce the 
metavariable F to range over effects. It is also convenient to introduce metavari- 
ables G, H to range over finite sets of groups. The following tables summarize 
these metavariable conventions and our enhanced syntax for types: 



Group Sets: 



G,H::={Gi,...,Gfc} 


finite set of groups 


Types: 


W ::= 


message type 


GIF] 


name in group G for ambients which contain 
processes with F effects 


Cap[F] 


capability (unleashes F effects) 


F :■= 


effect 


°n,T 


may open H, may exchange T 


S,T::= 


exchange type 


Shh 


no exchange 


Wi X ■ ■ ■ xWk 


tuple exchange 



The definition of free groups is the same as in Section 14 except that we 
redefine /^(W) by the equations / 5 (G[F]) = {G}Ufg{F) and fg{Cap[F]) = fg(F), 
and we define fg{F) = H U fg{T) where F = °H, T. 
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The following tables define the type system in detail. There are five ba- 
sic judgments as before. They have the same format except that the judgment 
E \- F, meaning that the effect F is good given environment E, replaces the 
previous judgment E \- T. We omit the three rules for deriving good environ- 
ments; they are exactly as in the previous section. There are two main differences 
between the other rules below and the rules of the previous section. First, ef- 
fects, F, replace exchange types, T, throughout. Second, in the rule (Exp Open), 
the condition G G H constrains the opening effect H of a capability open n to 
include the group G, the group of the name n. 



Judgments: 



A ho 


good environment 


EhW 


good message type W 


Eh F 


good effect F 


Eh M -.W 


good message M of message type W 


Eh P-.F 


good process P with F effects 



Good Types: 

I 1 

(Type Amb) (Type Cap) 

G € dom{E) Eh F Eh F 

EhG[F] EhCap[F] 



(Effect Shh) (Effect Prod) 

H C dom{E) Eho H C dom{E) E h Wi ■■■ E h Wk 



E h °H, Shh 


A h °H, Wi X • • • X Wfc 


Good Messages: 


(Exp n) (Exp e) 

E',n:W,E" ho E h Cap[E] 


E',n:W,E" h n : W Eh 


e : Cap[F] 


(Exp .) 

EhM:CaplF] E h M' : 


(Exp In) 

Cap[F] Ehn -.GIF] Ah°H,r 


E h M.M' : Cap[F] 


Eh inn: Cap[°H,T] 


(Exp Out) 

Ehn: G[F] Eh°U,T 


(Exp Open) 

Ehn:G[°U,T] GgH 


Eh out n: Gap[°H,T] 


E h open n : Gap[°H, T] 


Good Processes: 


1 

(Proc Action) 

EhM:Cap[F] EhP:F 


1 

(Proc Amb) 

Eh M : G[F] Eh P : F E h F' 



E h M[P] : F' 



E h M.P : F 
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(Proc Res) (Proc GRes) 

E,n:G[F] ^ P : F' F,G^P:F G j fg{F) 



F h {i^n:G[F])P : F' 


F h (^G)F 


' : F 


(Proc Zero) 
Fh F 


(Proc Par) 
Fh F : F 


F h Q : F 


(Proc Repl) 
Fh F : F 


Fh 0 : F 


F h F 1 


Q : F 


F h !F : F 


(Proc Input) 
F,ni:Wi ,. . . , 


rik-Wk h F : 


°H, Wi X • • • 


X Wk 


Fh 


.,nk-.Wk)-P 


: °H, Wi X • • • 


X Wk 


(Proc Output) 
F h Ml : 


■■■ F h Mfe : Wfc H C dom{F) 



S h (Ml, . . . , Mfc) : °H, IPi X • • • X Wk 



(Proc Go) 

Fh N: Cap[°H, T] F h M : G[F] F ^ P : F F \- F' 
F'r go N.M[P\ : F' 



15.2 Subject Reduction 

We obtain a subject reduction result. 

Theorem 2. If F \- P : F and P ^ Q then there are Gi, Gk such 
that Gi,...,Gk,Fh Q : F. 

Here is a simple example of a typing derivable in this system: 

G, n:G[°{G}, Shh] h n[0] | open n.O : °{G}, Shh 

This asserts that the whole process n[0] | open n.O is well- typed and opens only 
ambients in the group G. 

On the other hand, one might expect the following variant to be derivable, 
but it is not: 

G, n:G[°{}, Shh] h n[0] | open n.O : °{G}, Shh 

This is because the typing rule (Exp Open) requires the effect unleashed by the 
open n capability to be the same as the effect contained within the ambient n. 
But the opening effect °{} specified by the type G[°{}, Shh] of n cannot be the 
same as the effect unleashed by open n, because (Exp Open) also requires the 
latter to at least include the group G of n. 

This feature of (Exp Open) has a positive side-effect: the type G[°G,T] of 
an ambient name n not only tells which opening effects may happen inside the 
ambient, but also tells whether n may be opened from outside: it is openable 
only if G € G, since this is the only case when openn.O ] n[P] may be well-typed. 
Hence, the presence of G in the set G may either mean that n is meant to be 
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an ambient within which other ambients in group G may be opened, or that it 
is meant to be an openable ambient. 

More generally, because of the shape of the open rule, the opening effects 
in the ambient type of n not only record the openings that may take place 
inside the ambient, but also the opening effects of any ambient m which is going 
to open n, and, recursively, of any ambient which is going to open m as well. 
A similar phenomenon occurs with exchange types and with the subjective- 
crossing effects of the next section. 

While this turns out to be unproblematic for the examples we consider in 
these notes, one may prefer to avoid this “inward propagation” of effects by 
replacing (Exp Open) with the following rule: 

Ehn : G[°H,T] 

E h open n : Cap[°{{G} U H),T] 

With this rule, we could derive that the example process above, n[0] | 
open n.O, has effect °{G}, Shh, with no need to attribute this effect to pro- 
cesses running inside n itself, but unfortunately, subject reduction fails. To see 
this, consider the process open n \ n[open m], which can be assigned the effect 
°{G,H},Shh: 

G, H,m:G[°{}, Shh],n:H[°{G}, Shh] h open n\n[open m] : °{G, H}, Shh 

The process reduces in one step to open m, but we cannot derive the following: 
G, H, m:G[°{}, Shh],n:H[°{G}, Shh] h open m : °{G, H}, Shh 

To obtain a subject reduction property in the presence of the rule displayed 
above, we should introduce a notion of subtyping, such that if G C H and a pro- 
cess has type °G, T, then the process has type °H, T too. This would complicate 
the type system, as shown in [ZimOO]. Moreover, we would lose the indirect way 
of declaring ambient openability, so we prefer to stick to the basic approach. 



16 Crossing Control 

This section presents the third and final type system of these notes. We obtain 
it by enriching the type system of the previous section with attributes to control 
the mobility of ambients. 

16.1 The System 

Movement operators enable an ambient n to cross the boundary of another 
ambient m either by entering it via an inm capability or by exiting it via an outm 
capability. In the type system of this section, the type of n lists those groups 
that may be crossed; the ambient n may only cross the boundary of another 
ambient m if the group of m is included in this list. In our typed calculus, there 
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are two kinds of movement, subjective moves and objective moves, for reasons 
explained in Section 16.2. Therefore, we separately list those groups that may be 
crossed by objective moves and those groups that may be crossed by subjective 
moves. 

We add new attributes to the syntax of ambient types, effects, and capability 
types. An ambient type acquires the form G^G'[^X5,°H, T]. An ambient of this 
type is in group G, may cross ambients in groups G' by objective moves, may 
cross ambients in groups G by subjective moves, may open ambients in groups 
H, and may contain exchanges of type T. An effect, F, of a process is now of the 
form ^X5,°H,T. It asserts that the process may exercise in and out capabilities 
to accomplish subjective moves across ambients in groups G, that the process 
may open ambients in groups H, and that the process may exchange messages 
of type T. Finally, a capability type retains the form Cap[F], but with the new 
interpretation of F. Exercising a capability of this type may unleash F effects. 



Types: 



W ::= 

G"X?[F] 

Cap[F] 

F :■= 

^G,°H,T 
S',T ::= 

Shh 

Wi X ■ ■ ■ xWk 



message type 

name in group G for ambients which cross G 
objectively and contain processes with F effects 
capability (unleashes F effects) 
effect 

crosses G, opens H, exchanges T 
exchange type 
no exchange 
tuple exchange 



The definition of free groups is the same as in Section 14 except that we rede- 
fine fg{W) by the equations fg{G^G[F]) = {G} U G U fg{F) and fg{Cap[F]) = 
fg{F), and we define fg{F) = G U H U fg{T) where F = ^G,°H, T. 

The format of the five judgments making up the system is the same as in 
Section 15. We omit the three rules defining good environments; they are as 
in Section 14. There are two main changes to the previous system to control 
mobility. First, (Exp In) and (Exp Out) change to assign a type Gap[^G,°H,T] 
to capabilities in n and out n only if G € G where G is the group of n. Second, 
(Proc Go) changes to allow an objective move of an ambient of type G^G'[E] 
by a capability of type Gap[^G,°H,T] only if G = G'. 

Good Types: 

(Type Amb) (Type Cap) 

G € dom{E) G C dom{E) Eh F E F E 

EhG^G[F] EhCap[F] 

(Effect Shh) 

G C dom{E) H C dom{E) E \- o 



E h ^G,°H, Shh 
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(Effect Prod) 

G C dom{E) H C dom{E) E ^ Wi ■■■ E^Wk 
E h ^,°H, tPi X • • • X VPfc 



Good Messages: 

(Exp n) 

E',n-.W,E''^o 
E',n:W,E” 'rn-.W 

(Exp e) (Exp .) 

E h Cap[E] E'rM-.CaplF] E 'r M' ■. Cap[F] 
E'r Cap[F] Eh M.M' : Cap[F] 

(Exp In) 

Eh n:G^G'[F] Eh^G,°H,r GhG 
Eh inn: Cap[^G°H,T] 

(Exp Out) 

Ehn:G^G'[F] Eh^G,°H,r GeG 
Eh out n: Cap[^°H,T] 

(Exp Open) 

Eh n : G^G'[^G,°H,r] GgH 
E h open n : Cap[^G°'H.,T] 



Good Processes: 

(Proc Action) (Proc Amb) 

EhM:Cap[F] EhP:F EhM:G^G[F] EhP:f EhF' 
E h M.P : F Eh M[P] : F' 



(Proc Res) 

E,n:G^[F] h P : F' 
Eh {vn:G^G[F])P : F' 



(Proc GRes) 

E,GhP:F Gjfg{F) 
E h {vG)P : F 



(Proc Zero) 
EhF 
EhO : F 



(Proc Par) 

Eh P: F EhQ : F 
Eh P\Q : F 



(Proc Repl) 
Eh P: F 
Eh\P : F 



(Proc Input) 

E,nv.Wi,..., Uk-.Wk h P : ^,°H, lEi x ■ ■ ■ x IPfc 
Eh (ni:IPi,...,nfc:IEfc).P: -G,°H,IPi x • • • x IPfc 
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(Proc Output) 

E\- Mi:Wi ■■■ Mk'.Wk G C dom{E) H C dom{E) 

Eh x ■ ■ ■ x Wk 



(Proc Go) 

Eh N : Cap[^°ll,T] EhM:G^[E] EhP:E EhF' 
Eh go N.M[P\ : F' 



Theorem 3. If E h P : F and P ^ Q then there are G\, Gk such 
that Gi,...,Gk,Eh Q : F. 



16.2 The Need for Objective Moves 

We can now show how primitive typing rules for objective moves allow us to 
assign better types in some crucial situations. Recall the untyped example from 
Section 11. Suppose we have two groups Ch and Pk (for channels and packets). 
Let W be any well-formed type (where Ch and Pk may appear), and set P to 
be the example process: 



P = a[p[out a. in &.(c)]] | b[open p.{x\W).x\\] 



a-.Ch^{}r{},°{},Shh], 

b:Ch'^{}[^{Ch},°{Pk},W], 

c-.W, 

p: Pk } [^{ Ch},°{ Pk},W] 



and we can derive the typings: 



E h out a.in b.{c) : Ch},°{Pk}, W 

Eh open p.{x:W).x[] : ^{Ch},°{Pk},W 
Eh P: ^{},°{},Shh 



From the typing a : C7i ^{}[^{ },“{}, we can tell that a is an immo- 
bile ambient in which nothing is exchanged and that cannot be opened. From 
the typings p:Pk ^{}[^{Ch},°{Pk},W],b:Ch'^{}P{Ch},°{Pk},W], we can tell 
that the ambients b and p cross only Ch ambients, open only Pk ambients, and 
contain W exchanges; the typing of p also tells us it can be opened. This is not 
fully satisfactory, since, if b were meant to be immobile, we would like to express 
this immobility invariant in its type. However, since b opens a subjectively mo- 
bile ambient, then b must be typed as if it were subjectively mobile itself. The 
problem is quite general, as it applies to any immobile ambient wishing to open 
a subjectively mobile one. 

This problem can be solved by replacing the subjective moves by objective 
moves, since objective moves are less expressive than subjective moves, but they 
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cannot be inherited by opening another ambient. Let Q be the example process 
with objective instead of subjective moves: 

Q = a[go(out a. in 6).p[(c)]] | b[open p.{x\W).x\'^ 

Let 

E = Ch,Pk, 

b:Ch^{}r{}°{Pk},Wi 

c:W, 

p:Pk^{Ch}[^{}°{Pk},W] 

and we can derive: 

E h out a. in b : Cap[^{Ch} °{} , Shh] 

E h go{out a. in b).p[{c)] : ^{},°{}, Shh 
E \- open p.{x-.W).x\\ : ^{}°{Pk},W 
E^Q: ""{},°{}, Shh 

The typings of a and c are unchanged, but the new typings of p and b are 
more informative. We can tell from the typing p:Pk ^{Ch}['~^{} °{Pk} ,W] that 
movement of p is due to objective rather than subjective moves. Moreover, as 
desired, we can tell from the typing b:Ch W] that the ambient b 

is immobile. 

This example suggests that in some situations objective moves lead to more 
informative typings than subjective moves. Still, subjective moves are essential 
for moving ambients containing running processes. An extended example in the 
next section illustrates the type system of this section; the treatment of thread 
mobility makes essential use of subjective moves. 



17 Encoding a Distribnted Langnage 

In this section, we consider a fragment of a typed, distributed language in which 
mobile threads can migrate between immobile network nodes. We obtain a se- 
mantics for this form of thread mobility via a translation into the ambient cal- 
culus. In the translation, ambients model both threads and nodes. The encoding 
can be typed in all three of the systems presented in these notes; for the sake of 
brevity we describe the encoding only for the full system of Section 16. The en- 
coding illustrates how groups can be used to partition the set of ambient names 
according to their intended usage, and how opening and crossing control allows 
the programmer to state interesting invariants. In particular, the typing of the 
translation guarantees that an ambient modelling a node moves neither subjec- 
tively nor objectively. On the other hand, an ambient modelling a thread is free 
to move subjectively, but is guaranteed not to move objectively. 
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17.1 The Distributed Language 

The computational model is that there is an unstructured collection of named 
network nodes, each of which hosts a collection of named communication chan- 
nels and anonymous threads. This is similar to the computational models un- 
derlying various distributed variants of the pi calculus, such as those proposed 
by Amadio and Prasad [AP94] , Riely and Hennessy [RH98] , and Sewell [Sew98] . 
In another paper [CG99], we show how to mimic Telescript’s computational 
model by translation into the ambient calculus. In the language fragment we 
describe here, communication is based on named communication channels (as 
in the pi calculus) rather than by direct agent-to-agent communication (as in 
our stripped down version of Telescript). As in our previous paper, we focus on 
language constructs for mobility, synchronization, and communication. We omit 
standard constructs for data processing and control flow. They could easily be 
added. 

To introduce the syntax of our language fragment, here is a simple example: 

node a [channel Oc | thread\a^{b, be)]] ] node b [channel be] [ 
node c [thread[go a.ac{x:Node,y:Ch[Node]).go x.y{a)] 

This program describes a network consisting of three network nodes, named a, 
b, and c. Node a hosts a channel Qc and a thread running the code a^{b, be), which 
simply sends the pair (6, be) on the channel Qe- Node b hosts a channel be- Finally, 
node c hosts a single thread, running the code: 

go a.ae{x\Node, y.Ch[Node]).go x.y{a) 

The effect of this is to move the thread from node c to node a. There it awaits 
a message sent on the communication channel ae- We may assume that it receives 
the message (6, be) being sent by the thread already at a. (If there were another 
thread at node a sending another message, the receiver thread would end up 
receiving one or other of the messages.) The thread then migrates to node b, 
where it transmits a message a on the channel be- 

Messages on communication channels are assigned types, ranged over by Ty. 
The type Node is the type of names of network nodes. The type Ch[Ty-^^, . . . , Tyf,] 
is the type of a polyadic communication channel. The messages communicated 
on such a channel are fc-tuples whose components have types Ty■^^, . . . , Ty^.. In 
the setting of the example above, channel Oc has type Ch[Node, Ch[Node]], and 
channel be has type Ch[Node]. 

Next, we describe the formal grammar of our language fragment. A network, 
Net, is a collection of nodes, built up using composition Net [ Net and restric- 
tions {vn\ Ty)Net. A crowd, Cro, is the group of threads and channels hosted by 
a node. Like networks, crowds are built up using composition Cro [ Cro and re- 
striction {vn\Ty)Cro. A thread, T/i, is a mobile thread of control. As well as the 
constructs illustrated above, a thread may include the constructs fork (Cro). Th 
and spawn n [Cro].Th. The first forks a new crowd Cro inside the current node, 
and continues with Th. The second spawns a new node node n [Cro] outside the 
current node, at the network level, and continues with Th. 
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A Fragment of a Typed, Distributed Programming Language: 



'Ty ::= 


type 


Node 


name of a node 


Ch[Ty,,...,Ty^\ 


name of a channel 


Net ::= 


network 


{vn: Ty)Net 


restriction 


Net 1 Net 


network composition 


node n [Cro] 


node 


Cro ::= 


crowd of channels and threads 


{vn:Ty)Cro 


restriction 


Cro 1 Cro 


crowd composition 


channel c 


channel 


thread[Th] 


thread 


Th ::= 


thread 


go n. Th 


migration 


c{ni, ...,Uk) 


output to a channel 


c{xi:Tyi, . . . ,Xk-Tyf.).Th input from a channel 


fork {Cro). Th 


fork a crowd 


spawn n [Cro].Th 


spawn a new node 


In the phrases {un: Ty)Net and {vn\ Ty) Cro, the name n is bound; its scope is 
Net and Cro, respectively. In the phrase c{xi'.Ty-^^, . . . , Xk'-Tyjhj.Th, the names x\. 


. . . , Xk are bound; their scope is the phrase Th. 


The type system of our 


language controls the typing of messages on commu- 


nication channels, much as 


in previous schemes for the pi calculus [Mil99]. We 


formalize the type system using five judgments, defined by the following rules. 


Judgments: 




'Eho 


good environment 


E h n : Ty 


name n has type Ty 


Eh Net 


good network 


E h Cro 


good crowd 


Eh Th 


good thread 


Typing Rules: 



E\-<> n ^ dom{E) E,n:Ty, E' \~ o E,n:Ty\-Net 

0 h o E,n:Ty\-o E,n:Ty,E'\-n:Ty E \- {i/n:Ty)Net 



Eh Net Eh Net' 
Eh Net \ Net' 

E h Cro E h Cro' 
Eh Cro\ Cro' 



E h n : Node E h Cro E, n: Ty h Cro 
E h node n [Cro] E h {un: Ty) Cro 

Ehc: Ch[Ty„...,Tyf^] E h Th 

E h channel c Eh thread[Th] 
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g h n : Node E ^ Th 
E \- go n. Th 

Ehc: Ch[Ty,,...,Tyf,] 
E h c{xi'.Ty^ 



E\- c \ Ch[Tyi , . . . , Ty^] E \~ nt : Ty^ Vi G l..k 
E h c(ni, ...,Uk) 

E,xi:Ty^, . . .,Xk'.Ty^. h Th 
,...,Xk-Ty^).Th 



E'r Cro E^ Th Eh n: Node E ^ Cro E h Th 
E \- fork{Cro).Th E \- spawn n[Cro].Th 



17.2 Typed Translation to the Ambient Calculus 

In this section, we translate our distributed language to the typed ambient cal- 
culus of Section 16. 

The basic idea of the translation is that ambients model nodes, channels, 
and threads. For each channel, there is a name for a buffer ambient, of group 
Ch}’ , and there is a second name, of group Ch^ , for packets exchanged within 
the channel buffer. Similarly, for each node, there is a name, of group Node^, 
for the node itself, and a second name, of group Node^, for short-lived ambients 
that help fork crowds within the node, or to spawn other nodes. Finally, there is 
a group Thr to classify the names of ambients that model threads. The following 
table summarizes these five groups: 

Global Groups Used in the Translation: 

Node^ ambients that model nodes 

Node^ ambients to help fork crowds or spawn nodes 

Ch^ ambients that model channel buffers 

Ch^ ambients that model packets on a channel 

Thr ambients that model threads 



We begin the translation by giving types in the ambient calculus correspond- 
ing to types in the distributed language. Each type Ty gets translated to a pair 
|Ty]'’, {TyjP of ambient calculus types. Throughout this section, we omit the 
curly braces when writing singleton group sets; for example, we write ^Node^ 
as a shorthand for ^{Node^}. 

First, if Ty is a node type, [Tyf’ is the type of an ambient (of group Node’’) 
modelling a node, and {TyJP is the type of helper ambients (of group Node^). 
Second, if Ty is a channel type, {Ty'f’ is the type of an ambient (of group Chi’) 
modelling a channel buffer, and 17?/]^’ is the type of a packet ambient (of group 
ChP). 

Translations |Ty]^, \Ty\P of a Type Ty. 

\Nodef = 

Node’’ ^Node’’[^{}°Node^ , Shh] 
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iNodejP = 

NodeP ^Thrp'{}°NodeP , Shh] 
lCh[Ty„...,Ty^]f^ 

C/r" -{}[-{}, W, lTy,f X {TyjP x ■ ■ ■ x {Ty,f x [Ty.f] 
lCh[Ty„...,Ty,]r^ 

ChP^{Thr, Ch}r{}°ChP, {Ty,f x {Ty^r x • • • x {Ty,f x [Ty^f] 



These typings say a lot about the rest of the translation, because of the 
presence of five different groups. Nodes and helpers are silent ambients, whereas 
tuples of ambient names are exchanged within both channel buffers and packets. 
None of these ambients is subjectively mobile — in this translation only threads 
are subjectively mobile. On the other hand, nodes and helpers may both objec- 
tively cross nodes, while buffers are objectively immobile, and packets objectively 
cross both threads and buffers. Finally, both nodes and helpers may open only 
helpers, and both buffers and packets may open only packets (actually, the 
annotation inside the type of a packet of group means that can be 
opened, and similarly for helpers). 

Next, we translate networks to typed processes. A restriction of a single 
name is sent to restrictions of a couple of names: either names for a node and 
helpers, if the name is a node, or names for a buffer and packets, if the name 
is a channel. A composition is simply translated to a composition. A network 
node n is translated to an ambient named representing the node, containing 
a replicated open n^, where is the name of helper ambients for that node. 

Translation {Net] of a Network Net: 

liun:Ty)Netj = )|Aet] 

{Net I Net] = {Netj \ {Netj 

{node n [Cro]] = n^[\open \ IGroJ^] 



The translation IGroJn of a crowd is indexed by the name n of the node in 
which the crowd is located. Restrictions and compositions in crowds are trans- 
lated like their counterparts at the network level. A channel c is represented by 
a buffer ambient of group Ch^ . It is initially empty but for a replicated opencP, 
where is the name, of group of packets on the channel. The replication 
allows inputs and outputs on the channel to meet and exchange messages. 

An ambient of the following type models each thread: 

Thr ^{}PNode\°Sync, Shh] 

From the type, we know that a thread ambient is silent, that it crosses node 
boundaries by subjective moves but crosses nothing by objective moves, and 
that it may only open ambients in the Sync group. Such ambients help syn- 
chronize parallel processes in thread constructs such as receiving on a channel. 
A fresh group named Sync is created by a (vSync) in the translation of each 
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thread. The existence of a separate lexical scope for Sync in each thread implies 
there can be no accidental transmission between threads of the names of private 
synchronization ambients. 

Translation |CVo]„ of a Crowd Cro Located at Node n: 

l{iym:Ty)Crojn = )(i/TOP:|7?/p)|C'ro]„ 

|Cro I Crojn = ICrojn \ ICrojn 
\channel c]„ = c^[!open c^] 

\thread T/i]„ = 

{vSync){vt.Thr ^{\[^Node^ °Sync^ for t ^ /n(|T/i]^) 



The translation |T/i]^ of a thread is indexed by the name t of the thread 
and by the name n of the node in which the thread is enclosed. 

A migration go m. Th is translated to subjective moves taking the thread t 
out of the current node n and into the target node m. 

An output c(ni, . . . , Uk) is translated to a packet ambient that travels to 
the channel buffer c^, where it is opened, and outputs a tuple of names. 

An input c{xi'.Ty^, . . . , Xk-Tyf.).Th is translated to a packet ambient that 
travels to the channel buffer c^, where it is opened, and inputs a tuple of names; 
the tuple is returned to the host thread t by way of a synchronization ambient s, 
that exits the buffer and then returns to the thread. 

A fork fork {Cro). Th is translated to a helper ambient that exits the 
thread t and gets opened within the enclosing node n. This unleashes the crowd 
Cro and allows a synchronization ambient s to return to the thread t, where it 
triggers the continuation Th. 

A spawn spawn m [Cro].Th is translated to a helper ambient that exits 
the thread t and gets opened within the enclosing node n^. This unleashes an 
objective move go{out n*').m^[!open nrC \ |Cro]m]] that travels out of the node 
to the top, network level, where it starts the fresh node m^^.open \ ICroJ^]]. 
Concurrently, a synchronization ambient s returns to the thread t, where it 
triggers the continuation Th. 

Translation of a Thread Th Named t Located at Node n: 

Igo m.ThJli = out n.in to.|T7i]^ 

|c(ni, . . . = go{out t.in c^).c^[{ni,n \, . . . ,nfc,n^)] 

|c(xi:Tyi,...,a;fe:7?/fc).T/i]j, = 

{iys:Sync^{Thr, Ch}[^Node^ ,°Sync, Shh]) 

{go{out t.in c^). 

cP[{xl:lTyJ\xUTyir,---,4--lTy,f,xl:lTy,r). 
go{out c^.int).s[open s.lThjl^]] \ 
open s.s[]) 

for s ^ {^,c^cP} U/n(|T/i]j,) 



322 



Andrew D. Gordon 



lfork{Cro).Thji = 

{v S'. Sync ^ Thr N ode^ ° Sync, Shh]) 

{go outt.nP[go int.s\\ \ |Gro]„] \open s.|7’/i]^) 
for s ^ {t,nP} U |Cro]„ U |T/i]^ 

[spawn m [Cro].Thfn = 

{vs'.Sync^ThrY^Node^ ,°Sync, Shh]) 

{go out t.nP[go in f.s[] | go out .m^\\open m,P \ |CVo]m]] | 
open 

for s ^ {t,n’’,nP,m^,mP}Ufn{lCrojm)'Jfn{lThfJ 



Finally, we translate typing environments as follows. 

Translation |if] of an Environment E: 

|0] = Node\ NodeP, Ch\ ChP, Thr 
{E,c'.Tyl^{Elc'>'.{Tyf,cP'.lTyf 



Our translation preserves typing judgments: 

Proposition 1. 

(1) IfE'r Net then |E] h [Net] : "^{},°{}, Shh. 

(2) If E \- Cro and E \- n : Node then |E] h lOroJ^ : ^{},°{},Shh. 

(3) If E \- Th, E \- n : Node, t (f dom{E) then 

IE\, Sync, t'.Thr^{}[^Node'^,°Sync, Shh] h [ThU : ^Node\° Sync, Shh. 

Apart from having more refined types, this translation is the same as a trans- 
lation to the type system with binary annotations of [CGG99]. The translation 
shows that ambients can model a variety of concepts arising in mobile compu- 
tation: nodes, threads, communication packets and buffers. Groups admit more 
precise typings for this translation than were possible in the system with binary 
annotations. For example, here we can tell that a thread ambient subjectively 
crosses only node ambients, but never crosses helpers, buffers, or packets, and 
that it is objectively immobile; in the binary system, all we could say was that 
a thread ambient was subjectively mobile and objectively immobile. 

18 Discussion: The Ambient Calculus 

In this part, we introduced the ambient calculus as an abstract model for the 
mobility of hardware and software. We explained some of the type systems that 
have been proposed for ambients. We gave an application of the calculus as 
a semantic metalanguage for describing distributed computation. Our full type 
system tracks the communication, mobility, and opening behaviour of ambients, 
which are classified by groups. A group represents a collection of ambient names; 
ambient names belong to groups in the same sense that values belong to types. 
We studied the properties of a new process operator {vG)P that lexically scopes 
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groups. Using groups, our type system can impose behavioural constraints like 
“this ambient crosses only ambients in one set of groups, and only dissolves 
ambients in another set of groups” . 

18.1 Related Work on Types 

The ambient calculus is related to earlier distributed variants of the pi calculus, 
some of which have been equipped with type systems. The type system of Ama- 
dio [Ama97] prevents a channel from being defined at more than one location. 
Sewell’s system [Sew98] tracks whether communications are local or non-local, 
so as to allow efficient implementation of local communication. In Riely and 
Hennessy’s calculus [RH98], processes need appropriate permissions to perform 
actions such as migration; a well-typed process is guaranteed to possess the 
appropriate permission for any action it attempts. Other work on typing for mo- 
bile agents includes a type system by De Nicola, Ferrari, and Pugliese [DFP99] 
that tracks the access rights an agent enjoys at different localities; type-checking 
ensures that an agent complies with its access rights. 

Our groups are similar to the sorts used as static classifications of names in 
the pi calculus [Mil99]. Our basic system of Section 14 is comparable to Milner’s 
sort system, except that sorts in the pi calculus are mutually recursive; we would 
have to add a recursion operator to achieve a similar effect. Another difference 
is that an operator for sort creation does not seem to have been considered 
in the pi calculus literature. Our operator for group creation can guarantee 
secrecy properties, as we show in the setting of a typed pi calculus equipped 
with groups [CGGOOb]. Our systems of Sections 15 and 16 depend on groups to 
constrain the opening and crossing behaviour of processes. We are not aware of 
any uses of Milner’s sorts to control process behaviour beyond controlling the 
sorts of communicated names. 

Apart from Milner’s sorts, other static classifications of names occur in 
derivatives of the pi calculus. We mention two examples. In the type system 
of Abadi [Aba99] for the spi calculus, names are classified by three static secu- 
rity levels — Public, Secret, and Any — to prevent insecure information flows. In 
the flow analysis of Bodei, Degano, Nielson, and Nielson [BDNN98] for the pi 
calculus, names are classified by static channels and binders, again with the pur- 
pose of establishing security properties. (Similar flow analyses now exist for the 
ambient calculus [NNHJ99, HJNN99].) Although there is a similarity between 
these notions and groups, and indeed to sorts, nothing akin to our {vG) operator 
appears to have been studied. 

There is a connection between groups and the region variables in the work 
of Tofte and Talpin [TT97] on region-based implementation of the A-calculus. 
The store is split into a set of stack-allocated regions, and the type of each 
stored value is labelled with the region in which the value is stored. The scoping 
construct letregion pine allocates a fresh region, binds it to the region variable p, 
evaluates e, and on completion, deallocates the region bound to p. The constructs 
letregion p in e and {vG)P are similar in that they confer static scopes on 
the region variable p and the group G, respectively. One difference is that in 
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our operational semantics {vG)P is simply a scoping construct; it allocates no 
storage. Another is that scope extrusion laws do not seem to have been explicitly 
investigated for letregion. Still, we can interpret letregion in terms of as is 

reported elsewhere [DGOO]. 

18.2 Related Work on Ambients 

The introduction to this part, Section 10, is extracted from the original article 
on the ambient calculus [CGOOb]; more motivations may be found in another 
paper [Gar99], which develops a graphical metaphor for ambients, the folder 
calculus. 

The rest of this part reports research into type systems for the ambient calcu- 
lus, some parts of which have been described in conference papers. In [GG99] we 
have investigated exchange types, which subsume standard type systems for pro- 
cesses and functions, but do not impose restrictions on mobility; no groups were 
present in that system. In [GGG99] we have reported on immohility and locking 
annotations, which are basic predicates about mobility, still with no notion of 
groups; Zimmer [ZimOO] proposes inference algorithms for a generalization of 
this type system. In [GGGOOa] we introduce the notion of groups; much of this 
part of the notes is drawn from that paper. 

As well as work on types, there has been work on a variety of other tech- 
niques for reasoning about the ambient calculus. In [GG99], we define a form of 
testing equivalence for the ambient calculus, akin to the testing equivalence we 
introduced in Part II for the spi calculus; we develop some techniques for prov- 
ing testing equivalence including a context lemma. Several papers investigate 
program logics for the ambient calculus; in [GGOOa] we introduce a logic with 
both spatial modalities — for talking about the structure of ambient processes — 
and temporal modalities — for talking about their evolution over time. A recent 
paper extends the first with modal operators to express properties of restricted 
names [GGOl]. Two other papers investigate the equivalence induced by the 
logic [SaiiOl] and the complexity of the model checking problem [CDG“''01]. 

Levi and Sangiorgi [LSOO] propose a variant of the calculus called Safe Am- 
bients. As well as the original in, out, and open capabilities, they introduce 
three dual capabilities, written in, out, and open, respectively. To enter a sib- 
ling named n, an ambient needs to exercise the out n capability, as before, but 
additionally, the sibling needs to exercise the out n capability. Similarly, to exit 
its parent named n, an ambient needs to exercise the out n capability, as before, 
but additionally, the parent needs to exercise the out n capability. To dissolve 
an ambient named n, its environment needs to exercise the open n capability, 
as before, but additionally, the ambient itself needs to exercise the open n capa- 
bility. The resulting ambient calculus is a little more complicated than the one 
described here, but the advantages shown by Levi and Sangiorgi are that certain 
race conditions may be avoided, and in some ways more accurate typings are 
possible. Bugliese and Gastagna [BGOl] investigate an extension of Safe Ambi- 
ents intended to describe security properties; their notion of ambient domain is 
akin to the notion of group discussed in these notes. 
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The first implementation of the ambient calculus was a Java applet [Car97]. 
More recent implementations support mobility between machines distributed 
on a network; they include an implementation of the original calculus using 
Jocaml [FLSOO], and of Safe Ambients using Java RMI [SVOl]. 

Acknowledgement C.A.R. Hoare and G. Castagna commented on a draft of these 
notes. 
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Abstract. In the recent years, many formalizations of security proper- 
ties have been proposed, most of which are based on different underlying 
models and are consequently difficult to compare. A classification of se- 
curity properties is thus of interest for understanding the relationships 
among different definitions and for evaluating the relative merits. In this 
paper, many non-interference-like properties proposed for computer secu- 
rity are classified and compared in a unifying framework. The resulting 
taxonomy is evaluated through some case studies of access control in 
computer systems. The approach has been mechanized, resulting in the 
tool CoSeC. Various extensions (e.g., the application to cryptographic 
protocol analysis) and open problems are discussed. 

This paper mainly follows [21] and covers the first part of the course 
“Classification of Security Properties” given by Roberto Gorrieri and 
Riccardo Focardi at FOSAD’OO school. 



1 Introduction 

The wide spread of distributed systems, where resources and data are shared 
among users located almost everywhere in the world, has enormously increased 
the interest in security issues. In this context, it is likely that a user gets some 
(possibly) malicious programs from an untrusted source on the net and executes 
them inside its own system with unpredictable results. Moreover, it could be 
the case that a system completely secure inside, results to be insecure when 
performing critical activities such as electronic commerce or home banking, due 
to a “weak” mechanism for remote connections. It is important to precisely de- 
fine security properties in order to have formal statements of the correctness of 
a security mechanism. As a consequence, in the recent years there have been 
a number of proposals of formal definitions of security properties (see, for in- 
stance, [1,2,8,11,12,17,21,30,44,45,51,53,59,60]). 

* This work has been partially supported by MURST projects TOSCA, “Certificazione 
automatica di programmi mediante interpretazione astratta” and “Interpretazione 
astratta, type systems e analisi control-flow”, and also partially supported by Mi- 
crosoft Research Europe. 
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In this paper we deal with a particular class of security properties, called 
information flow properties, which aim at controlling the way information may 
flow among different entities. They have been first proposed as a means to ensure 
confidentiality, in particular to verify if access control policies are sufficient to 
guarantee the secrecy of (possibly classified) information. Indeed, although access 
control is a well studied technique for system security, it is not trivial to find an 
access control policy which guarantees that no information leak is possible. One 
of the main problems is to limit, and possibly to avoid, damages produced by 
malicious programs, called Trojan Horses, which try to leak secret information. 

For example, consider a classic Diseretionary Access Control security (DAC 
for short), where every subject (i.e., an active agent such as a user), decides 
the access properties of its objects (i.e., passive agents such as files). The file 
management in Unix is a classic example of DAC. Indeed it allows users to decide 
the access rights on their files. This flexibility may facilitate security leakages. 
As an example, if a user A executes a Trojan Horse program, this can directly 
modify the access properties of A’s objects making, e.g., all A’s data visible to 
every other user. In this respect, we can say that the DAC approach gives no 
guarantees against “internal” attacks. 

A different approach to this problem is the Mandatory Access Control (MAC 
for short), where some access rules are imposed by the system. Even if we have 
executed a Trojan Horse program, its action will be limited since it is not allowed 
to change MAC rules. An example of MAC is Multilevel Security [5]: every object 
is bound to a security level, and so is every subject; information can flow from 
a certain object to a certain subject only if the level of the subject is greater 
than the level of the object. So a Trojan Horse, which operates at a certain level, 
has in principle no way to downgrade information, and its action is restricted to 
that level. This policy can be implemented through two access rules: No Read 
Up (a subject cannot read data from an upper level object) and No Write Down 
(a subject cannot write data in a lower level object). 

However, even if we adopt the less flexible MAC approach, this could be 
insufficient to stop the action of a Trojan Horse. Indeed, it could be possible 
to transmit information indirectly using system side effects. For example, if two 
levels - ‘high’ and ‘low’ - share some finite storage resource (e.g., a hard disk), 
it may be possible to transmit data from level ‘high’ to level ‘low’ by exploiting 
the ‘resource full’ error message. For a high level transmitter, it is sufficient to 
alternatively fill or empty the resource in order to transmit a ‘1’ or a ‘0’ datum. 
Simultaneously, the low level receiver tries to write on the resource, decoding 
every error message as a ‘1’ and every successful write as a ‘O’. It is clear that such 
indirect transmissions, called covert channels, do not violate the two multilevel 
access rules (see Figure 1). Therefore it is often necessary to integrate a MAC 
discipline with a covert channel analysis (see, e.g., [63]). 

The existence of covert channels has led to the more general approach of 
information flow security, mentioned above. The idea is to try to directly control 
the whole flow of information, rather than the accesses of subjects to objects [36]. 
By imposing some information flow rules, it is possible to indifferently control 



Classification of Security Properties 333 




Fig. 1. Information flows in multilevel security 



direct and indirect leakages, as, in this perspective, they both become “unwanted 
information flows” . 

In the literature, there are many different security definitions reminis- 
cent of the information flow idea, each based on some system model (see, 
e.g., [36,64,41,48,49,62,7]). In [24] we have compared and classified them, lead- 
ing to our proposed notion of Bisimulation Non Deducibility on Compositions 
{BNDC, for short). We will present BNDC starting by the idea of Non Inter- 
ference [36] . Through a running example and a comparison with other existing 
approaches, we will try to convince the reader that such a property can effectively 
detect unwanted information flows in systems, both direct and indirect. 

We now describe the topics of the next sections. Section 2 presents the Secu- 
rity Process Algebra (SPA, for short) language. All the properties we will present 
and apply to the analysis of systems and protocols are based on such a language. 
SPA is an extension of CCS [50] - a language proposed to specify concurrent 
systems. The basic building blocks are the atomic activities, simply called ac- 
tions; unlike CCS, in SPA actions belong to two different levels of confidentiality, 
thus allowing the specification of multilevel (actually, two-level) systems. As for 
CCS, the model used to describe the operational semantics of SPA is the labelled 
transition system model [43] , where the states are the terms of the algebra. In or- 
der to express that certain states are indistinguishable for an external observer, 
semantic equivalences over terms/states are defined such that two terms are ob- 
servationally indistinguishable iff they are equivalent. As explained below, the 
information flow security properties we introduce are all based on these notions 
of observable behaviours. 

Section 3 is about such properties, that capture the existence of information 
flows among groups of users. We will see that these properties are all of the 
following algebraic form. Let E be an SPA process term, let A be a security 
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property, let « be a semantic equivalence among process terms and let Cx and 
T>x be two SPA contexts^ for property X . Then, we can say: 

E is A-secure if and only if Cx [E] « Vx [E] . 

where the contexts Cx and T>x are such that only (part of) the low behaviour 
of E becomes observable; hence, the behavioural equivalence compares these, 
possibly different, low behaviours of E. 

A first obvious consequence is that the security properties become paramet- 
ric w.r.t. the chosen notion of equivalence: if an equivalence is finer than 
~2 then each security property based on is satisfied by a subset of the pro- 
cesses satisfying the corresponding security property based on « 2 - A second, 
less obvious consequence is that such information flow properties are not safety 
properties, i.e. properties that can be specified as sets of acceptable behaviours. 
Indeed, by defining a property of this form for E as an equivalence problem 
- Cx[E] « VxlE] - on suitable contexts, we are actually stating that if some 
behaviour can occur, then it must be the case that also some other related be- 
haviour must be possible; such a property cannot be expressed simply as a set 
of acceptable behaviour. 

We analyze which kinds of flows are detectable by the various properties 
through the running example of an access monitor. In particular, we try to show 
that certain properties are not appropriate to deal with some kinds of information 
flows and so it is necessary to strengthen them by choosing a finer equivalence 
notion or, if this is not enough, by following a different approach. 

In Section 4 we present a tool called Compositional Security Checker (CoSeC, 
for short) which can be used to check automatically (finite state) SPA specifi- 
cations against some information flow security properties. We exploit the alge- 
braic definition style. Indeed, checking the A-security of E is reduced to the 
“standard” problem of checking semantic equivalence between two terms having 
E as a sub-term. The CoSeC tool has the same modular architecture as Con- 
currency Workbench (CW for short) [14], from which some modules have been 
imported, and others modified. The tool is equipped with a parser, which trans- 
forms an SPA specification into a parse-tree; then, for the parsed specification 
CoSeC builds the labelled transition system following the operational rules de- 
fined in Plotkin’ SOS style [54]. When a user wants to check if an SPA process E 
is A-secure, CoSeC first provides operational semantic descriptions to the terms 
Cx[E] and T>x[E] in the form of two LTSs; then verifies the semantic equivalence 
of Cx[E] and T>x[E] using their lts representations. An interesting feature of 
CoSeC is the exploitation of the compositionality of some security properties in 
order to avoid, in some cases, the exponential state explosion due to the parallel 
composition operator. 

^ An SPA context Q is an SPA term “with a hole”. E.g., G[—] = F — . The insertion 
of E in the context G, written as G[E], has the effect of filling the hole with E. In 
the example, G[E] = E + E. Subscript A simply means that Cx and T>x are two 
particular contexts for property A, i.e., it is used to give a name to contexts for 
property X. 
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Finally, in Section 5 we give some concluding remarks and discuss some open 
problems. 



2 SPA and Value-Passing 

In this Section we present the language that will be used to specify and analyze 
security properties over concurrent systems. We first present the “pure” version 
of the language. Then we show how to extend it with value-passing. Finally, we 
present an example of value-passing agent specification. It will be our running 
example for the next sections. 

2.1 The Language 

The Security Process Algebra (SPA for short) [24,26] is a slight extension of 
Milner’s CCS [50], where the set of visible actions is partitioned into high level 
actions and low level ones in order to specify multilevel systems. ^ 

SPA syntax is based on the same elements as CCS. In order to obtain a par- 
tition of the visible actions into two levels, we consider two sets Actn and AcIl 
of high and low level actions which are closed with respect to function “ (i.e., 
ActH = Act Hi ActL = ActL)', moreover they form a covering of C and they 
are disjoint (i.e., Actn U Acth = -C, Actu C ActL = 0). Let Act be the set 
Actn U ActL U {r}, where r is a special unobservable, internal action. The syn- 
tax of SPA agents (or processes) is defined as follows: 

E ::=0 \ (J..E \ E + E \ E\E | A\\L | E[f] | Z 

where fi ranges over Act, L C C and / : Act — > Act is such that f{a) = 
/(a), /(r) = T. Moreover, for every constant Z there must be the corresponding 
definition: Z E, and E must be guarded on constants. This means that the 
recursive substitution of all the non prefixed (i.e., not appearing in a context 
fJ..E') constants in E with their definitions terminates after a finite number of 
steps. In other words, there exists a term obtainable by constant substitutions 
from E where all the possible initial actions are explicitly represented (through 

def def 

the prefix operator pL.E). For instance, agent A = B with B = Ais not guarded 
on constants. On the contrary, if B is defined as a. A, then B is guarded on 
constants. This condition will be useful when we will do automatic checks over 
SPA terms. As a matter of fact, it basically avoids infinite constant substitution 
loops. 

Intuitively, we have that 0 is the empty process, which cannot do any action; 
pL.E can do an action p, and then behaves like E] E\ -\- E 2 can alternatively 

^ Actually, only two-level systems can be specified; note that this is not a real limita- 
tion because it is always possible to deal with the multilevel case by grouping - in 
several ways - the various levels in two clusters. 
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choose ^ to behave like Ei or E 2 ; Ei\E 2 is the parallel composition of Ei and E 2 , 
where the executions of the two systems are interleaved, possibly synchronized 
on complementary input/output actions, producing an internal r; E\\L can 
execute all the actions E is able to do, provided that they do not belong to L; 
if E can execute action then E[f] performs /(^). 

The only other difference from CCS is the restriction operator \\ ; as we said 
above, E\\L can execute all the actions E is able to do, provided that they do 
not belong to L. In CCS the corresponding operator \ requires that the actions 
do not belong to L U L. We will show in a moment that it is easy to define the 
standard restriction operator of CCS using this new restriction. The reason why 
we introduce this slight modification is that it is necessary to define an additional 
input restriction operator which will be useful in characterizing some security 
properties in an algebraic style. After that we will have no further use for the 
\\ operator. We define the CCS restriction and the input restriction operators 
as follows: 



E\L = E\\LU L 
E\i L = E\\Lnl 

E \ L is the CCS restriction operator, while E\i L requires that the actions of 
E do not belong to L C / 

For the definition of security properties we also need the hiding operator of 
CSP [39] which can be defined as a relabelling as follows: 

E/L E[fL] where fL{x) = | ^ ^ f ^ 

E jL turns all the actions in L into internal r’s. 

Let £ be the set of SPA agents, ranged over by E and F. Let C{E) denote the 
sort of E, i.e., the set of the (possibly executable) actions occurring syntactically 

in E. The sets of high level agents and low level ones are defined as £h {A G 
£ I C{E) C Actn U {t}} and £l'^= {E & £ \ C{E) C Act^ U {t}}, respectively. 
From a security point of view, processes in £h and in £l are secure by isolation, 
as all the actions they perform are bound to one particular level (high or low, 
respectively). More interesting is the case of processes in £h iJ £l C £, i.e., of 
those processes that execute both high level and low level actions, allowing for 
communications between the two levels, hence possibly introducing unwanted 
information flows. 



2.2 Operational Semantics and Equivalences 

The operational semantics of SPA is the lts {£, Act, — !■), where the states are the 
terms of the algebra and the transition relation £ x Act x £ is defined as for 

^ For notational convenience, we use sometimes the ^ operator (indexed on a set) to 
represent a general n-ary (or even infinitary) sum operator. 
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Table 1. The operational rules for SPA 



Prefix 

li.E E 

T? 77 ' 77 77 ' 

^ -C/i -C/2 ^ -C/2 

Sum 

El +E2-^ E'l Ei+E2^ E'2 



Parallel 



Restriction 



Relabelling 



Constant 



El A E'l 



-52 As' 



77 77 ' 77 77 ' 

£/l — > H/i - C /2 — ^ - C /2 



-B1I-B2 A -E1IA2 Ae^iI^:' S1I-B2 a 



E^E' 



E\\L-^ E'\\L 



if // 0 L 






A[/l -5'[/l 



E-^ E' 
E' 



if A Af 



CCS by structural induction as the least relation generated by the axioms and 
inference rules reported in Table 1. The operational semantics for an agent E is 
the subpart of the SPA lts reachable from the initial state E. We denote with 
£ps the set of all the SPA agents with a finite lts as operational semantics. 
Table 2 shows some simple examples of SPA terms with their corresponding ltss. 
Now we introduce the idea of observable behaviour: two systems should have 
the same semantics if and only if they cannot be distinguished by an external 
observer. To obtain this we define an equivalence relation over states/terms of 
the SPA LTS, equating two processes when they are indistinguishable. In this 
way the semantics of a term becomes an equivalence class of terms. 

It is possible to define various equivalences of this kind, according to the 
different assumptions on the power of observers. We recall three of them. The 
first one is the classic definition of trace equivalence, according to which two 
agents are equivalent if they have the same execution traces. The second one 
discriminates agents also according to the nondeterministic structure of their 
LTSS. This equivalence is based on the concept of bisimulation [-50]. The last one, 
introduced for the CSP language [39], is able to observe which actions are not 
executable after a certain trace {failure sets), thus detecting possible deadlocks. 

Since we want to focus only on observable actions, we need a transition 
relation which does not take care of internal t moves. This can be defined as 
follows: 

Definition 1. The expression E =A> E' is a shorthand for E{^)*E\ A A 2 (A)* 
E' , where (A)* denotes a (possibly empty) sequence ofr labelled transitions. Let 
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Table 2. Some simple SPA terms 



Prefix: Ei = a.O 



a 





7 = cti . . . G £* be a sequence of actions; then E ^7 E' if and only if there 
exist El, E 2 , ■ ■ ■ , En-i € £ such that E =k^ E\ ■■■ An-i E' . 

For the empty sequence () we have that E E' stands for E{£^)*E' . We say 
that E' is reachable from E when 37 : E ^7 E' and we write E E' . ■ 

Trace Equivalence We define trace equivalence as follows: 

Definition 2. For any E G £ the set T{E) o/traces associated with E is defined 
as follows: T{E) = {7 g £* | 3E' : E E'}. E and E are trace equivalent 
(notation E E) if and only ifT(E) = T(E). ■ 
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Fig. 2. Systems not observationally equivalent 



Observational Equivalence Bisimulation is based on an idea of mutual step- 
by-step simulation, i.e., when E executes a certain action moving to E' , E must 
be able to simulate this single step by executing the same action and moving to 
an agent E' which is again bisimilar to E' (this is because it must be able to 
simulate every successive step of E'), and vice-versa. 

A weak bisimulation is a bisimulation which does not care about internal 
T actions. So, when F simulates an action of E, it can also execute some r 
actions before or after that action. 

In the following, E E' stands for E A' if /i S £, and for E {^)* E' 
if fj, = T (note that (^)* means “zero or more r labelled transitions” while 
requires at least one r labelled transition). 

Definition 3. A relation R C £ x £ is a weak bisimulation if {E, F) G R 
implies, for all p G Act, 

— whenever E — ^ E' , then there exists F' G £ such that F F' and 

{E',F')gR; 

— conversely, whenever F F' , then there exists E' G £ such that E E' 
and {E',F') G R. 

Two SPA agents E,F G £ are observationally equivalent, notation E ksb F, if 
there exists a weak bisimulation containing the pair (E,F). ■ 

In [50] it is proved that ws is an equivalence relation. Moreover, it is easy to 
see that E F implies E F; indeed, if E F then F must be able to 
simulate every sequence of visible actions executed by E, i.e., every trace of F; 
since the simulation corresponds to the execution of the actions interleaved with 
some t’s, then every trace of E is also a trace for F. Symmetrically, E must be 
able to simulate every sequence of F. So E F. 

In Figure 2 there is an example of two trace-equivalent systems which are not 
observationally equivalent. In fact both E and F can execute the three traces a, 
ab and ac. However, it is not possible for E to simulate step-by-step process F. In 
particular, F executes a and moves to a state where it can execute both b and c. 
Process E can simulate this first step of F but, after this, it cannot simulate F 
anymore since it is in a state where it can execute only b or c. 
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£’ 



F’ 




Fig. 3. Observational equivalence detects deadlocks 



This ability of observing the branching structures of systems makes « b able 
to detect potential deadlocks. If we consider E' ‘^= if \{c} and F' F\{c} (see 
Figure 3) we have that E' and F' are still trace equivalent but not observationally 
equivalent. Indeed, system E' can reach a deadlock state after the execution of 
action a. On the other hand, F' is not able to simulate this move since after a 
it can always execute b. 

We conclude this section about bisimulation by introducing the notion of 
weak bisimulation up to It will be very useful when proving that two agents 
are observation equivalent. Indeed, we see that in order to ensure P Q it is 
sufficient that (P,Q) is in some weak bisimulation up to ~ b - 

Definition 4. A relation S C SxS is a weak bisimulation up to if {E, F)gS 
implies, for all p € Act, 

— whenever E E' , then there exists F' G £ such that F F' and 
E’ ^ ~B F'; 

— conversely, whenever F F' , then there exists E' G £ such that E E' 

and E' KiB S F' . 

where S is the composition of binary relations, so that E' k,b S k,b F' 
means that for some E" and F" we have E' k,b F” , {E" ,F") G S, F' k,b F" . 



In [.50] it is proven the following result: 

Proposition 1. If S is a hisimulation up to ~b then S 

Hence, to prove P ~b Q, only have to find a bisimulation up to which 
contains (P,Q). This is one of the proof techniques we will often adopt in the 
following. 

Failure/Testing Equivalence The failure semantics [9], introduced for the 
CSP language, is a refinement of the trace semantics where it is possible to 
observe which actions are not executable after a certain trace. In particular, 
a system is characterized by the so-called failures set, i.e., a set of pairs (s,X) 
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where s is a trace and X is a set of actions. For each pair (s, X), the system must 
be able, by executing trace s, to reach a state where every action in X cannot 
be executed.^ For instance, consider again agents E' and F' of Figure 3. As we 
said above, E' can stop after the execution of a and, consequently, E' can refuse 
to execute action b after the execution of a. So E' has the pair (a, {6}) in its 
failure set. System F' is always able to execute b after the execution of a. So F' 
does not have (a, {6}) in the failure set, hence it is not failure equivalent to E' . 
We deduce that also failure semantics is able to detect deadlocks. Moreover, also 
systems E and F of Figure 2 are not failure equivalent. 

A different characterization of failure equivalence (called testing equivalence) 
has been given in [52]. It is based on the idea of tests. We can see a test T as 
any SPA process which can execute a particular success action lo ^ C. X test T 
is applied to a system E using the parallel composition operator j . A test T may 
be satisfied by system E if and only if system (E\T) \ C can execute oj. Note 
that in system {E\T) \ £ we force the synchronization of E with test T. 

Definition 5. E may T if and only if (E\T) \ C {E'\T') \ C ■ 

A maximal computation of (E\T) \ £ is a sequence (E\T) \ £ = ETq ET\ 

. . . ^ ETn ^ . . . which can be finite or infinite; if it is finite the last term must 
have no outgoing transitions. A test T must be satisfied by E if and only if every 
maximal computation of (E\T) \ £ contains a state ETi which can execute to. 

Definition 6. E must T if and only if for all maximal computations of ETq = 
{E\T) \ £, 3i such that ET, ^ ET' ■ 

Now we can define testing equivalence as follows: 

Definition 7. Two systems E and F are testing equivalent, E ~test F, if and 
only if 

i) E may T ^ F may T 
ii) E must T ^ F must T 

for every test T. ■ 

It is easy to see that the first condition holds if and only if E F. In fact, 
if E may satisfy T, then E is able to execute the trace which moves T to the 
state where it can execute w. ® It is not difficult to see that the second condition 
corresponds to failure equivalence. The basic idea is that if E fails to execute 
a certain action a after a trace 7, we can detect this with a test T which executes 
the complementary actions of 7 followed by a, and then executes lu. In fact, for 
that T we have that E mfist T. 

^ Indeed, there is a condition on the traces s in pairs (s, X). It is required that during 
any execution of s no infinite internal computation sequences are possible. We will 
analyze this aspect more in detail in the following. 

® We could have more than one trace or more than one oj. However if a system may 
satisfy a test T, then it may satisfy also a test T' with only one oj and only one trace 
to it. T' corresponds to one of the traces executed by the system in order to satisfy 
the test T. 
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8 




Fig. 4. Systems testing equivalent but not observationally equivalent 



a 

A’ 



b 




Fig. 5. Systems observationally equivalent but not testing equivalent 



We have seen that both and «test are stronger than since they 
basically observe something of the branching structure of the LTSs. However we 
have said nothing about the relation between these two equivalences. The reason 
is that they are incomparable, i.e., no one of them implies the other. Indeed, 
we have that is in most cases more sensitive than ^test to the branching 
structure of the agents. We can see this in the simple example of Figure 4. It 
shows that does not permit to “shift” the non-deterministic choice even if 
the first actions executed after the branch are exactly the same (b, in this case). 

On the other hand «test is more discriminating with respect to divergent 
behaviour, i.e., infinite sequences of internal r actions. Indeed, a divergence may 
“ruin” a test by generating unexpected maximal computations. As an exam- 
ple, see Figure 5 where the divergence after a in process B' determines that 
B' m]/st a.b.uj.O while A must d.b.uj.O. This happens because, after the execu- 
tion of a, the process could diverge never reaching the w success action. This 
aspect will be analyzed more in detail in the next chapters, when we will try to 
use «test in the specification of security properties. 

We conclude this section presenting a class of finite state agents. This will be 
useful in the automatic verification of security properties. This class of agents 
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consists of the so-called nets of automata: 



P 



o\p-p\p + p\ z 



E 



p \ E\E \ E\L I E\iL I E/L \ E[f] 



def 



where for every constant Z there must be the corresponding definition Z = p 
(with p guarded on constants) . It is easy to prove that every agent of this form 
is finite state. However, this condition is not necessary, in the sense that other 
agents not belonging to the class of nets of automata are finite state as well. For 

def def 

instance, consider B = a.0-|-Zi\{i} with D = i.{o.Q\D). It can execute only an 
action a and then it stops, so it is clearly finite state. However note that it does 
not conform to the syntax of nets of automata since there is a parallel operator 
underneath a sum. 

2.3 Value-Passing SPA 

In this section we briefly present a value-passing extension of “pure” SPA (VSPA, 
for short). All the examples contained in this paper will use this value passing 
calculus, because it leads to more readable specifications than those written 
in pure SPA. Here we present a very simple example of a value-passing agent 
showing how it can be translated into a pure SPA agent. Then we define the 
VSPA syntax and we sketch the semantics by translating a generic VSPA agent 
into its corresponding SPA agent. 

As an example, consider the following buffer cell [50] : 



where a; is a variable that can assume values in N (we usually write a; S N). 
C reads a natural number n through action in and stores it in variable x. Then 
this value is passed to agent C which can give n as output through action out 
moving again to C. So C represents a buffer which may hold a single data item. 
If we assume that in is a low level action and out a high level action, then C is 
a system exhibiting a legitimate direct information flow from low to high. On the 
contrary, if in is high and out is low, then C is an insecure system, downgrading 
information from high to low. 

Now we show how C can be translated into an SPA agent. The parametrized 
constant C becomes a family of constants C' one for each value S N. Similarly 
out{x) becomes a family outy of prefixes. So the single definition for C' becomes 
the following family of definitions: 



Now consider the prefix in{x). To reflect the fact that it can accept any in- 
put value, binding variable x, we translate it into definition 



C = in{x).C'{x) 
C'{x) out{x).C 




outy.C {v S N) 
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becomes: 

U6]N 

VSPA is very similar to the value-passing CCS introduced in [50]. The main 
difference is that in VSPA we can have more than one parameter for actions and 
parameters are multi-sorted. 

The syntax of VSPA agents is defined as follows: 

A ::= 0 I a{xi, . . . ,Xn)-E | a(ei, . . . , e„).A | t.E | A -|- A | E\E | 

I E\L I E\iL I E/L I E[f] \ \ 

I if b then if | if 6 then E else E 

where the variables x\, . . . ,Xn, the value expressions ei, . . . , e„ and ... ,e'^ 
must be consistent with the arity of the action a and constant A, respectively 
(the arity specifies the sorts of the parameters), and 6 is a boolean expression. 
The arity of actions and constants is given by function ari. This function returns 
a tuple of sets (called Sorts) that represent the ranges of the parameters for the 
specific action or constant considered. For example, ari{a) = (^i, . . . , S'„) means 
that action a has n parameters with ranges Si, . . . , Sn, respectively. 

It is also necessary to define constants as follows: A{x \, . . . , Xm) E where 
if is a VSPA agent which may contain no free variables except X\, . . . , Xm, which 
must be distinct. As in [50] the semantics of the value-passing calculus is given 
as a translation into the pure calculus. The translations rests upon the idea that 
a single label a of VSPA, with n parameters with sorts Si . . . Sn, becomes the 
set of labels : Vi G S'i,Vi G [l,n]} in SPA. We consider only agents 

without free variables because if an agent has a free variable then it becomes a 
family of agents, one for each value of the variable. The translation can be given 
recursively on the structure of agents. Note that, since we have no free variable 
all the value and boolean expressions can be calculated; we will write b and e for 
the value obtained by evaluating a boolean expression b and a value expression e 
respectively. 

We will use the notation if{a/6} to represent agent E with all the occurrences 
of b substituted by a. We will also use 8'^ to denote the set of VSPA agents. 
For each agent E G without free variables, its translation |if] is given in 
Table 3 where ari{a) = Si .. . Sn] L = ■ I € L, ari{l) = Si .. . Sn, Vi G 

Si,\/i G [l,n]} is the set of the translations of actions in L and f{lvi,...,v„) = 
f{l)vi,...,vn is the translation of relabelling function /. Furthermore, the single 

definition A{xi , . . . , Xm) E with ari{A) = Si .. . Sm, is translated to the set 
of equations: 

vi,...,Vm — \E{vi! Xi, ■ ■ ■ I ^ Si^i G [1, m] } 

Note that we do not partition the set of actions into two levels; we directly 
refer to the partition in the pure calculus. In this way it is possible for a certain 
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Table 3. Translation of VSPA to SPA 



egs+ 


lEjGE 


0 


0 


a(xi, . . . , Xn).E 


Sieil.ral.UieSj ^i’l,---,Vn-\E{vi /xi, . . . Vn/Xn}\ 


d{ei, . .., en).E 




t.E 


r-lE} 


El + E 2 


[All + [As] 


Ei\E2 


[AillIAs] 


E\L 


{E\\L 


E\iL 


[A] \r L 


E/L 


IE\/L 


m 


m\f] 


A(ei, . . . , e„) 


4— — 

■^ei ,6n 


if b then E 


I [A] if b= True 
1 0 otherwise 



action in VSPA to correspond, in the translation, to actions at different levels in 
SPA. This can be useful if we want a parameter representing the level of a certain 
action. As an example consider an action access_r{l, x) with I G {high, low} and 
X € representing a read request from a user at level I to an object a;; we 

can assign the high level to the actions with I = high and the low level to the 
others in this way: access-r(high, x) G Actn and access j'{low,x) G Act^ for all 
X G[l,n].^ 

A VSPA agent is finite state if its corresponding SPA agent is so. Hence, 
in general, a necessary condition is that every variable can assume values over 
a finite set only. 

2.4 The Access Monitor 

Here we give a more complex example of a VSPA agent specification. It is an 
access monitor which handles read and write requests on two binary variables 
enforcing the multilevel security policy. We will analyse and modify this example 
in the next sections in order to assess the merits of the various information flow 
properties that we will propose. 

Example 1. Consider the system in Table 4 where x,y,z,l G {0,1}, L = {r,w} 
and Vi G {0,1} we have r(l,i), w(l,i), access-r(l,i), val(l,i), val(l, err), 



Note that access-r(high,x) stands for accessjrhigh,x, with x G [l,n]. Indeed, for the 
sake of readability, we often write c(v) instead of its translation Cv ■ 
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Table 4. The Access J\donitor_l System 



Access Alonitor A = (Monitor \ Object(l,0) \ Object(0,0))\ L 
Monitor accessjr(l,x). 

(if X < I then 

r(x, y).val(l, y). Monitor 
else 

val(l, err). Monitor) 

+ 

accessjw(l, x).write(l, z). 

(if X > I then 

w(x, z). Monitor 
else 

Monitor) 

def 

Object(x,y) = r(x,y).Object(x,y) + w(x, z).Object(x, z) 



accessjw(lA)TWf’ite(l,i) S Actn and all the other actions are low level ones. 
Note that in Access Jelonitor A every variable can assume values over a finite 
set only. When we translate it into SPA, we obtain a net of automata, hence 
Access -Monitor A is a finite state agent 

Figure 6 represents process Access -Monitor -1 that handles read and write 
requests from high and low level users on two binary objects: a high level variable 
and a low level one. It achieves no read up and no write down access control 
rules allowing a high level user to read from both objects and write only on the 
high one; conversely, a low level user is allowed to write on both objects and read 
only from the low one. Users interact with the monitor through the following 
access actions: access-r(l,x),access-w(l,x),write{l, z) where I is the user level 
(Z = 0 low, I = 1 high), X is the object (x = 0 low, x = 1 high) and z is the 
binary value to be written. 

As an example, consider access_r(0, 1) which represents a low level user 
(I = 0) read request from the high level object (x = 1), and access_w(l, 0) 
followed by write(l,0) which represents a high level user (I = 1) write request 
of value 0 (2 = 0) on the low object (x = 0). Read results are returned to 
users through the output actions val(l,y). This can be also an error in case of 
a read-up request. Note that if a high level user tries to write on the low object 
- through access-w(l, 0) followed by write(l, z) - such a request is not executed 
and no error message is returned. 

In order to understand how the system works, let us consider the following 
transitions sequence representing the writing of value 1 in the low level object. 
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Fig. 6. The Access Monitor for Example 1 



performed by the low level user: 

{Monitor \ Object{l,0) \ Object{0,0)) \ L 

{write{0, z).W{0, z). Monitor \ Object{l,0) \ Object{0,0)) \ L 
— ^ (w(0, 1). Monitor \ Object{l,0) \ Object{0,0)) \ L 

{Monitor \ Object{l, 0) | Object{0, 1)) \ L 

The trace corresponding to this sequence of transitions is 

accessjw{0, 0).write{0, 1) 

and so we can write: 

{Monitor \ Object{l,0) \ Object{0,0)) \ L 

{Monitor \ Object{l, 0) | Object{0, 1)) \ L 

Note that, after the execution of the trace, the low level object contains value 1. 

Access Jilonitor A is a value passing specification of an access monitor. Its 
translation into CoSeC syntax for pure SPA is reported in Table 12 of Section 4.4. 
As an example, here we provide the translation of Object{x, y) into the pure 
calculus by means of the following four constant definitions: 

def 

Objectoo = roo-Objectoo + Woo.Objectoo + Woi.Objectoi 

def 

Objectoi = rQi.Objectoi + woo-Objectoo + woi-Objectoi 

def 

Objectio = riQ.Objectio + wio-Objectio + wii-Objectii 
Objectii fii.06jectii + wiq. O bjectio + wu.Objectu 



Note that we have, for every possible value of the pair {x,y), one different process 
Obj ectxy ■ ■ 
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3 Information Flow Properties 

In this Section we present some Information Flow properties. The common in- 
tuition behind all these properties is strictly related to the classic notion of Non 
Interference (NI, for short) [36], i.e., the low level users should not be able to 
deduce anything about high level users’ activity. 

As already mentioned earlier in this chapter, processes in £h or £]^ are secure 
by isolation, as they are confined to work in one single confidentiality level. The 
really interesting processes are those built with both high level and low level 
actions, as they may show unwanted information flows. 

In the first three sections we present properties based on different equivalence 
notions. We start with the weakest and most intuitive one: trace equivalence. 
Then, we see that it is necessary to move to finer equivalence notions in order 
to detect possible high level deadlocks that can compromise the security of the 
system. For this reason, in the second section we base our security properties 
on failure and testing equivalences [9,52], which have been designed specifically 
to detect deadlocks. However, we discover that the failure/testing setting is not 
ideal for our purposes because of the way it deals with (potential) divergences. 
This leads us, in the third section, to prefer to base our security properties on the 
notion of weak bisimulation. In the fourth section we show that deadlocks due 
to high level activity are indeed dangerous and cannot be ignored. In section 3.5 
we compare our security properties with other proposals in the literature which 
are also based on Process Algebras. 

Part of the material contained in this section has been published in [24] , [26] , 
[21], [23], [22], [18]. 

3.1 Properties Based on Trace Equivalence 

We start with Non- deterministic Non Interference (NNI, for short) [24,26], 
which is a natural generalization to non-deterministic systems of NI (assum- 
ing two user groups only) . The basic idea of NI is that the high level does not 
interfere with the low level if the effects of high level inputs are not visible by a 
low level user. This idea can be rephrased on the LTS model as follows. We con- 
sider every trace 7 of the system containing high level inputs. Then, we look if 
there exists another trace 7 ' with the same subsequence of low level actions and 
without high inputs. A low level user, which can only observe low level actions, 
is not able to distinguish 7 and 7 '. As both 7 and 7 ' are legal traces, we can 
conclude that the possible execution of the high level inputs in 7 has no effect 
on the low level view of the system. 

As for NI, we can define this property by using some functions which manip- 
ulates sequences of actions. In particular, it is sufficient to consider the function 
low : C* — > which takes a trace 7 and removes all the high level actions 
from it, i.e., returns the low level subsequence of 7 . Moreover we use the func- 
tion highinput : C* — > (Act//n/)* which extracts from a trace the subsequence 
composed of all the high level inputs. 
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Definition 8. (NNI: Non- deterministic Non Interference) 

E G NNI if and only ifWj € T{E), 3(5 G T(E) such that 

(i) low{'j) = low{S) 

(ii) highinput{S) = () 

where () denotes the empty sequence. ■ 

This may be expressed algebraically as: 

Proposition 2. E € NNI 4=^ (E \j Actn) / Actn E/Actn. 

Proof. (=i>) It is enough to show that if E is NNI then T{E / Actn) Q T{{E \/ 
Actn) /ActH)^ because the opposite inclusion simply derives from T{E\jActH) C 
T{E). Let 7 e T^E/Actn)', then, by definition of / operator, 3y' e T(E) such 
that low{Y) = 7- Since E G NNI then 3(5 S T{E) such that low{Y) = low{S) 
and highinput{5) = (). Hence 5 € T{E \j Actn) and S' = low{5) G T{{E \j 
Actn)/ Actn). Since 7 = low{^') = low{5) = S', then 7 = 5' and thus 7 G 
T{{E \[ Actn)/ Actn). 

(4=) Let 7 G T{E). Then 3(5 G T{E \/ Actn) such that lowi^j) = low{S). Since 
S G T{E\i Actn) then highinput{S) = () and S G T{E). ■ 

As a matter of fact, in E/Actn all the high level actions are hidden, hence 
giving the low level view of the system; E \/ Actn instead prevents traces from 
containing high level inputs. So, if the two terms are equivalent, then for every 
trace with high level inputs we can find another trace without such actions but 
with the same subsequence of low level actions. 

In the following we will consider this algebraic characterization as the defi- 
nition of NNI. Indeed, all the other properties we present below in this section 
are defined using this compact algebraic style. An interesting advantage of this 
style is that it reduces the check of a security property to the “standard” and 
well studied problem of checking the semantic equivalence of two ltss. 

It is possible to prove that Access JMonitor A of Example 1 is NNI. In fact, 
the next example shows that NNI is able to detect whether the multilevel access 
control rules are implemented correctly in the monitor. 

Example 2. Consider the modified monitor ^ in Table 5 which does not control 
write accesses: Now it is possible for a high level user to write in the low level 
object (action accessjw{l, 0) followed by write{l, z)) so the system is not secure. 
We have that NNI is able to detect this kind of direct flow. Access _Monitor_2 
can execute the following trace: 

7 = access.w{l, 0).write{l, 1). access jr{0, 0).val{0, 1) 

In 7 we have two accesses to the monitor: first a high level user modifies the value 
of the low object writing down value 1, and then the low user reads value 1 from 
the object. If we purge 7 of high level actions, we obtain the sequence 

7' = access-r(0, 0).val(0, 1) 

^ In the following, if an agent is not specified (e.g. Object{x,y)) we mean that it has 
not been modified with respect to the previous versions of the Access Monitor. 
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Table 5. The Access-Monitor J2 System 



Access-Monitor J2 = {Monitor A \ Ohject{l,t)) \ Object{0,0)) \ L 
Monitor J2 access-r{l, x). 

{if X < I then 

r{x, y).val{l, y). Monitor-2 

else 

val{l, err).MonitorJ2) 

+ 

access-w{l, x).write{l, z).w{x, z). Monitor-2 



representing the reading by a low level user of value 1 from the low object. This 
trace is not a legal trace for Access-MonitorJI since the low object is initialized 
to value 0. Moreover, it is not possible to obtain a trace for Access-MonitorJI 
by adding to 7' only high level outputs, because all the high level outputs in 
Access -Monitor -2 are prefixed by high level inputs. Hence 7' is not even a trace 
for {Access-Monitor-2 \/ Actn) /Actn ■ In other words, it is not possible to find 
a trace 7" of Access -Alonitor -2 with the same low level actions of 7 and without 
high level inputs. 

Since 7' is a trace for agent Access -Monitor -2/ Actn but it is not a trace for 
agent {Access-Monitor J2 \j Actn)/ Actn, we conclude that Access-M onitorJ2 
is not NNI. ■ 

The example above shows that NNI reveals if something is wrong in the access 
policy we are implementing. Indeed, it is quite intuitive that if some access rule 
is missing then there will be a particular execution where some classified infor- 
mation is disclosed to low level users (otherwise such a rule would be useless). 
This will certainly modify the low level view of the system making it not NNI 
for sure. 

However, the next example shows that NNI is not adequate to deal with 
synchronous communications and, consequently, it is too weak for SPA agents. 

Example 3. Consider Access -AIonitor-1, and suppose that we want to add a high 
level output signal which informs high level users about write operations of low 
level users in the high level object. This could be useful to know the integrity 
of high level information. We obtain the VSPA agent of Table 6 with the new 
written-up action and where Vf € {0, 1}, written-up{i) S Actn- 

It is possible to prove that Access -Monitor -3 is NNI. However, consider the 
following trace of Access -Monitor -3: 



7 = access-w{0, 1) .write{0,0) .written-up{0) .access-w{0, l).write(0, 0) 
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Table 6 . The Access-Monitor Ji System 



Access-Monitor Ji = {Monitors \ Object{l,0) \ Object{0,0)) \L 
Monitors access-r{l, x). 

{ it X < I then 

r(x, y).val{l, y). Monitors 

else 

val{l, err). Monitors) 

+ 

access-w{l, x).write{l, z). 

( if X = I then 

w(x, z). Monitors 
else 

if X > I then 

w{x, z) .written-up{z) .M onitor S 
else 

Monitor -A) 



where a low level user writes two times value 0 into the high level object. If 
we purge 7 of high level actions (i.e. of written-up) we obtain the following 
sequence: 



7 ' = access-w(0, l).write(0, 0).access-w(0, l).write(0, 0 ) 

that cannot be a trace for Access -Monitor -3, because after every low level write 
operation there must be an action writteu-up. 

So, if a low level user succeeds in executing the two write requests, then 
(s)he will know that some high level user has “accepted” the high level output 
written-up (because of synchronous communications). In other words, a high 
level user can interfere with a low level one accepting or not the high level 
output written-up. NNI is not able to detect this, because it verifies only the 
high level input interferences over low level actions. In fact, since 7 is a trace 
of Access-Monitor S, then 7' is a trace for both Access-Monitor S/ Act h and 
{Access-M onitor -3\i Act H)/ActH- ■ 

The example above shows that synchronous communications induce a symmetry 
over inputs and outputs. For this reason, we define a symmetric form of NNI . It 
requires that, for every trace 7, the sequence 7', obtained from 7 by deleting all 
the high level actions, is still a trace. This property is called Strong NNI {SNNI 
for short). 
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Definition 9. E a SNNI E/AcIh E \ Actn- ■ 

We have that AccessJ\donitorJi is not SNNI since 7 ' is a trace for the agent 
Access-Monitor A/ Actn and 7 ' is not a trace for Access-MonitorA \ Actn- 
The reason why the name “Strong NNP has been chosen is a consequence of 
the following result: 

Proposition 3. SNNI C NNI. 

Proof. If if g SNNI then E/Actn E\Actn- Since T{E\ActH) C T{{E\i 
Actu) / Actu) and T{{E\j Actn) / Actn) Q T{E / AcIh) then E G NNI. The 
inclusion is strict because E = h.l.Q is NNI but not SNNI . ■ 

It is thus possible to prove that Access -Monitor A of Example 1 is also SNNI . 

SNNI seems to be quite satisfactory in a trace equivalence setting. Unfor- 
tunately, in the following example, we will see that trace equivalence - as the 
basic equivalence for security properties ~ is too weak; in particular, it is not 
able to detect deadlocks due to high level activities, that influence the security 
of a system. 

Example 4- Suppose we have a high level action hstop which explicitly stops 
the monitor. Obviously, in such a case there is a possible deadlock caused by 
a high level activity. In particular, consider the system in Table 7 where hstop G 



Table 7. The Access -Monitor -4: System 



Access -Monitor -4 = {Monitor -4 \ Ohject{l,9) I Object(0,0)) \L 
Monitor-4 accesss{l,x). 

( if X < Z then 

r(x, y).val{l, y). Monitor-4 
else 

val{l, err). Monitor -4) 

+ 

access-w{l, x).write{l, z). 

{ if X > I then 

w{x, z). Monitor -4 
else 

Monitor -4) 

+ 

h-stop.O 



Actn- It is possible to prove that it is SNNI. This is because trace equivalence 
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is not able to detect deadlocks and h^stop does not modify the low traces of 
the system. It could seem that a deadlock caused by a high level activity is 
not really interfering with any low level users, since a low level user, trying 
to make an access to the monitor, is not able to conclude that the monitor is 
blocked. However such a user can obviously deduce that the system is not blocked 
every time it accepts some access requests or gives some outputs. In the case of 
Access -Monitor A, a low level user will never be able to conclude that hstop 
has been executed; nonetheless, at every interaction with the system, the user 
will know that Access -Monitor -4 is not blocked and so that hstop has not been 
executed yet. In section 3.4 we will show how the subtle information flow caused 
by a potential deadlock can be exploited in order to construct an information 
channel from high level to low level. ■ 

In order to detect this kind of flows, it is necessary to use some notion of equiva- 
lence which is able to detect deadlocks. Note that by simply changing the equiv- 
alence notion in the definition of SNNI we obtain a security property which 
inherits all the observation power of the new equivalence notion. So, for detect- 
ing deadlocks, one obvious possibility could be the failure/testing setting [9,52], 
that has been designed for this purpose. 

3.2 Detecting High Level Deadlocks through Failure/ Testing 
Equivalences 

Consider the version of SNNI based on testing equivalence: 

Definition 10. (testing SNNI) E € TSNNI E/Actn ^test E \ Actjj ■ 

We have that Access -Monitor -4 ^ TSNNI. In fact it is sufficient to consider 
the test T = access_r(0, 0).w.0 which is able to detect the deadlock introduced 
by action hstop. In particular, we have that: 

Access -Monitor -4 \ Actu must T 
Acce ss -Monitor -4/ Act H mpfst T 

Intuitively, when we hide hstop in Access-AI onitor-4/ Act h we obtain an inter- 
nal transition to a deadlock state. If the system moves to that state before the 
execution of access-r(0, 0) the test will not be satisfied. 

So, it seems that TSNNI is exactly the deadlock-sensitive extension of SNNI 
we were looking for. However, in the following we want to show that for systems 
with some high level loops or with r loops, TSNNI is not interesting and is not 
able to detect security flaws. This is caused by the way testing equivalence deals 
with divergences (infinite sequences of r actions). In fact, it is possible to prove 
that if E is divergent, then the (failure) condition (ii) of «test is verified if and 
only if also F is divergent. In the failure setting, when we have a divergent state 
we can observe the behaviour of a process only before reaching that state. All 
the actions after a divergence cannot be observed. In section 2.2, we have seen 

^ of ^ of /^t»f 

that A! = a. 6.0 is not testing equivalent to B' = a.B” with B" = t.B" + 6.0. 
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Fig. 7. Divergence makes A and B non testing equivalent 



The only difference between A and B' is the divergence after the execution of a 
in B' (see Figure 7). 

Now, consider a system E with some high level loops and without divergences. 
When we hide high level actions in TSNNI with operation E/Actn, we obtain 
some T loops and so E/Actn is divergent. As we said above, this will be failure 
equivalent to if \ Actn only if if \ Actn is divergent as well. However since E is 
without divergences, E \ Actn cannot have divergences too. We conclude that 
this kind of systems cannot be TSNNI no matter what the interactions between 
high and low level actions are. Note that every recursive high level system (with 
no low level actions and so secure by definition) is of this kind. All the access 
monitors we have seen so far have this feature as well. 

Moreover we have an even worse situation if we consider a divergent pro- 
cess D, as also D \ Actn and D/Actn are divergent. So for these two processes 
(ii) is verified. This means that for divergent processes »test becomes equal to 
wt- Hence TSNNI becomes equal to SNNI and, in general, all the properties 
based on testing equivalence become equal to the corresponding ones based on 
trace equivalence. Now, we present an example of a divergent TSNNI process 
which, nonetheless, contains some high level deadlocks. 

Example 5. Consider again agent Access-MonitorA. We want to add a backup 
feature which is able to make a copy of the values stored in objects periodically. 
Obviously, there should be also a recovery procedure, but we do not model this 
in order to simplify as much as possible the example. We have a first process 
which represents the backup timer and sends periodically a signal in order to 
obtain a backup. It is an abstraction of a clock, since in SPA it is not possible 
to handle time directly. 



BackupJtimer = backup. BackupJtimer 

Then we slightly modify the Monitor process by inserting two actions which 
suspend its execution until the backup is finished. 

Monitor J3 . 

the same as in Access JMonitor A 



+ start Joackup. end Joackup. Monitor 
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The backup process is enabled by the timer, then it stops the monitor, reads 
the values of variables, stores them into two additional objects {Object{2, y) and 
Object(3,y)) and resumes the monitor: 

Backup backup. 

startjjackup. 

r{0,y).r{l,z). 

w{2,y).w{3,z). 

end-backup. 

Backup 

The access monitor with backup is given by the following system: 

def 

Access -MonitorJ3 = {Monitor-B \ Backup-timer \ Backup \ Object{0,0) \ 

I Object{l,0) I Object(2,0) \ Object{S,0)) \ L 

where L = {r, w, start-backup, endJ)ackup, backup}. As a result, the backup pro- 
cedure of the system is something internal, i.e., an external user can see nothing 
of the backup task. This makes the system divergent. In fact, if the variable val- 
ues are unchanged, then the backup procedure is a r loop that moves the system 
to the same state where it started the backup. For weak bisimulation this is not 
a problem and we can analyze this new system as well. In particular, we can 
check with the CoSeC tool (presented in Section 4) that Access -Monitor-B is 
observationally equivalent to Access -Monitor -A. This is enough to prove (The- 
orem 5) that every security analysis made on Access -Monitor -A is valid also for 
Access -M onitor -B . In particular. Access -Monitor-B is not secure because of 
the potential high level deadlock we have explicitly added in Access -Monitor -A. 

On the other hand, if we try to analyze this system with some testing equiv- 
alence based property, we have an inaccurate result. Indeed Access-M onitor-B , 
differently from Access -Monitor -A, is TSNNI. This happens because process 
Access -Monitor-B is divergent and so processes Access-M onitor-B / Act h and 
{Access-M onitor -B\n) \ Actn (V7T € £h) are divergent as well. Thus they are 
failure equivalent and, since Access -Monitor-B is SNNI they are also trace (and 
so testing) equivalent. ■ 

There is also an interesting, practical difference between bisimulation and fail- 
ure/testing. On the one hand, it is possible to check bisimulation (observational 
equivalence) in polynomial time [42]. On the other hand, we have that the prob- 
lem of establishing language equivalence of nondeterministic finite automata is 
reducible in polynomial time to the problem of checking any of the testing, 
failure, and trace equivalences. Such a problem has been proved to be PSPACE- 
complete [61]. The consequence is that all these problems are PSPACE-complete 
as well. 

Moreover it is interesting to observe that failure/ testing equivalences are 
not known to be decidable on infinite state systems. On the other hand, there 
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are some interesting results on the decidability of weak bisimulation over some 
classes of infinite state systems, e.g. totally normed Basic Process Algebras 
(BPA) [38].® For instance it is possible to define a BPA agent representing an 
unbounded queue. 

All these arguments have convinced us to adopt bisimulation and observa- 
tional equivalence as the default semantic equivalence for our properties. 

In the next section we move to weak bisimulation and observational equiv- 
alence. As we have seen, these notions are able to detect deadlocks as well. 
Moreover they give a fair interpretation of divergence, i.e., they assume that 
a T loop will be executed an arbitrary, yet finite, number of times. In this way 
they can observe system behaviour also after divergences. 



3.3 Properties Based on Observational Equivalence 

We introduce the bisimulation-based security properties BNNI and BSNNI, by 
substituting for in their SPA-based definitions. 

Definition 11. (Bisimulation NNI, SNNI) 

(i) E G BNNI E/Actu {E\i Act h)/ A ct u 

(ii) E e BSNNI ^ E/Actn E\ Actn ■ 

As expected, it can be proved that each of these new properties is properly finer 
than its corresponding trace-based one. 

Proposition 4. The following hold: 

{i) BNNI C NNI, 

(ii) BSNNI c SNNI, 

Proof. It immediately follows from the fact that E ksb E implies E E. The 
inclusions are proper because E = t.1.0 + r.h.l.O is such that E G NNI , SNNI 
and E ef BNNI, BSNNI. ■ 

Consider again Access -Monitor A containing the hstop event. It is neither 
BSNNI nor BNNI, as observational equivalence is able to detect deadlocks. In 
particular. Access -Monitor -A/ Actn can move to 0 through an internal action 
T, while Access -Monitor -A \ Actn is not able to reach (in zero or more r steps) 
a state equivalent to 0. 

Now we want to show that BSNNI and BNNI are still not able to detect some 
potential deadlocks due to high level activities. This will induce us to propose an- 
other property based on a different intuition. Let us consider Access -Monitor-!. 
We can prove that such a system is BSNNI as well as BNNI. However, the fol- 
lowing two dangerous situations are possible: (i) a high level user makes a read 



BPA [6] are basically the transition systems associated with Greibach normal form 
(GNF) context-free grammars in which only left-most derivations are permitted. In 
order to obtain an lts an action is associated with every rule. 
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Fig. 8. BNDC intuition 



request without accepting the corresponding output from the monitor (remem- 
ber that communications in SPA are synchronous) and (ii) a high level user 
makes a write request and does not send the value to be written. In both cases 
we have a deadlock due to a high level activity that BNNI and BSNNI are not 
able to reveal. To solve this problem, we are going to present a stronger prop- 
erty, called Bisimulation-based Non Deducibility on Compositions (BNDC, for 
short). It is simply based on the idea of checking the system against all high 
level potential interactions. A system E is BNDC if for every high level process 
n a low level user cannot distinguish E from {E\II) \ Actn- In other words, 
a system E is BNDC if what a low level user sees of the system is not modified 
by composing any high level process U to E (see Figure 8). 

Definition 12. E is BNDC iff 'ill e £h, E/Actn (A | U) \ Actn- ■ 

Example 6. We want to show that Access-Monitor A is not BNDC. Consider 
n = access-r{l, 1).0. System [Access -Monitor-1 \ H) \ Actn will be blocked 
immediately after the execution of the read request by II, moving to the following 
deadlock state: 

{{val[l, 0). Monitor \ Object[0, 0) | Object[l, 0)) \ L | 0) \ Actn 

This happens because II executes a read request and does not wait for the 
corresponding return value (action val). We conclude that II can interfere with 
low level users. Since there are no possible deadlocks in Access JMonitor-l /Actn, 
we find out that [Access-Monitor-l\II)\ActH Access-Monitor-l/Actn and 
so Access -Monitor-1 is not BNDC. 

Moreover, there is another potential source of deadlock when a high level user 
makes a write request and does not send the value to be written. In particular, the 



358 



Riccardo Focardi and Roberto Gorrieri 



val(l,y) 




High 

Level 

Users 



Low 

Level 

Users 



Fig. 9. The BNDC Access-Monitor 



high level user II' = access -w{l, 0).0 will block system {Access-M onitor -1\II')\ 
Actu immediately after the execution of the write request by II' , moving the 
system to the following deadlock state: 

{{{write{l,0).w{l,0).Monitor + write{l,l) A) -Monitor) \ Object{0,0) \ 

I Object{l, 0)) \ L I 0) \ Actn 

Again, we have (Access-M onitor-l\II') \ActH Acce ss -M onitor-!/ Act h- In 

order to obtain a BNDC access monitor, we modify the monitor by adding an 
interface for each level which temporarily stores the output value of the moni- 
tor (passing it later to the users and thus making communication asynchronous) 
and that guarantees mutual exclusion within the same level; moreover, we use an 
atomic action for write request and value sending. Note that, because of the in- 
terface, actions access-r, access-W and val become a_r, a-W and put, respectively. 
The resulting system is reported in Table 8 (see also Figure 9). 

In such a system we have that k G {0,1, err}, I = {r, w}, N = {val, 
access-r, accessjw} and a_r(l,x), a_?n(l,x), put{l,y) G Actn Va; G {0,1} and 
Vy G {0, 1, err}, while the same actions with 0 as first parameter belong to Actj^. 
It is possible to verify that Access -Monitor -5 is BNDC using the automatically 
checkable property we are going to present. Table 9 summarizes the properties 
satisfied by the different versions of the access monitor. ■ 

The next theorem shows that the bisimulation-based properties are related in 
a different way with respect to the corresponding ones. Indeed, we have that 
BNDC is stronger than BNNI and BSNNI. Moreover BSNNI (f. BNNI while 
for trace equivalence we had that SNNI C NNI . BSNNI 

Theorem 1. 

(i) BNNIg BSNNI and BSNNI % BNNI 
(a) BNDCC BSNNI n BNNI 
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Table 8. The Access-Monitor System 



Access Alonitor-b = {AM \ Inter f) \ N 

r\(3f 

AM = (Monitor-5 \ Object{l,0) \ Object{0,0)) \ L 
Monitor-5 access-r(l,x). 

{ if X < I then 

r{x, y).val{l, y). Monitor-5 
else 

val{l, err). Monitor -5) 

+ 

access-w{l, x, z). 

{ if X > I then 

w{x, z). Monitor-5 
else 

Monitor -5) 

Inter/ Inter /{(/) \ Interf{l) 

Inter f{l) ajr{l, x). access -T (I, x).val{l, k).put{l, k).Interf{l) 

+ 

a-w{l, X, z).access-w(l, x, z) .Inter f (1) 



Proof. (*) Let us consider the following agent E = l.h.l.h.l.O + l.l.l.O + l.l.O; 
we have that E G BNNI and E ^ BSNNI. Let us now consider the agent 
F = l.h.l.h.l.O + l.l.l.O + l.O] we have that F € BSNNI and F ^ BNNI. 

(a) To show that BNDC C BSNNI, consider W = 0 (the empty process). 
Then, by BNDC definition, we have that E/Actn ~b {E \ 0) \ Actn and so 
E / Actfj Kig E \ Actn ■ 

To show that BNDC C BNNI, consider U" = ^i^Acinni process 
which accepts all the high inputs) then, by BNDC definition, we have that 
E/Actn (if I U'')\ActH- Now it is sufficient to note that (E \ II'')\ActH ~b 
(E \i ActH)/Ac±H- 

In order to show that the inclusion is strict we need a system which is both 
BSNNI and BNNI, and which is not BNDC. Such a system is E = l.h.l.h.l.O + 
l.l.l.O + l.O. It is easy to see that it is BSNNI and BNNI. Moreover if we consider 
n'” = h.O we obtain that (E \ II"') \ Actn l.l.O + l.l.l.O + l.O ^b E. ■ 

We need another simple result before we can draw a diagram of the relations 
among all the properties we have seen up to now. 

Proposition 5. BNNI % SNNI. 
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Fig. 10. The inclusion diagram for bisimulation-based properties 



Proof. It is sufficient to consider agent E = h.l.Q which is BNNI but not SNNI. 



Figure 10 summarizes the relations among the bisimulation-based properties 
presented so far. 

It is now interesting to study the trace equivalence version of BNDC called 
NDC . Indeed it could improve the SNNI property which is still our better pro- 
posal for the trace equivalence setting (no detection of deadlocks). Surprisingly, 
we find out that such property is exactly equal to SNNI . 

Theorem 2. NDC = SNNI. 

Proof. We first prove that if if € NDC then E S SNNI. By hypothesis, 

E/Actn ~T {E\0)\ActH for the specific 77 = 0. Since {E\0)\ActH E\Ad,H 

then we have E /Actn ~t E \ Actn ■ 

Now we want to prove that if if G SNNI then E € NDC. By hypothesis, 

E/Actn ~T E \ Actn- Since T{E \ Actn) C T((if|i7) \ Actn) then we have 

T{E / Actu) C T{{E\n) \ Actn)- Observe also that the reverse inclusion holds, 
in fact, if E and 77 synchronize on a certain high action, then E/Actn can always 
“hide” it. Hence E/Actn \ H)/ActH. ■ 



Table 9. Properties satisfied by the different versions of the access monitor 



Ver. 


Description 


NNI 


SNNI 


BNNI 


BSNNI 


BNDC 


1 


Multilevel rules 


X 


X 


X 


X 




2 


Without write control 












3 


With high signal for integrity 


X 










4 


With explicit high level deadlock 


X 


X 








5 


With buffers and atomic write 


X 


X 


X 


X 


X 
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This, in a sense, confirms that the intuition behind SNNI (and so NI) is good 
at least in a trace equivalence model. Indeed, in such a model the fact that we 
check the system against every high level process is useless. It is sufficient to 
statically check if the hiding of high level actions corresponds to the restric- 
tion of such actions. This points out a critical point: BNDC is difficult to use in 
practice, because of the universal quantification on high level processes. It would 
be desirable to have an alternative formulation of BNDC which avoids univer- 
sal quantification, exploiting local information only as for the trace-equivalence 
case; even if Martinelli has shown that BNDC is decidable over finite state pro- 
cesses [47], a solution to this problem is still to be found. In the same work, 
Martinelli also shows a negative fact regarding the verification of BNDC: it is 
not compositional, i.e., if two systems are BNDC their composition may be not 
so. This does not permit us to reduce the BNDC-secuiity of a big system to the 
BNDC-secmity of its simpler subsystems and forces us to always prove BNDC 
over the whole system. 

For these reasons, here we propose a sufficient condition for BNDC, namely 
the SBSNNI property, which exploits local information only and moreover is 
compositional (i.e., if two systems are SBSNNI their composition is SBSNNI 
too). 

Definition 13. (SBSNNI: Strong BSNNI) 

A system E G SBSNNI if and only if for all E' reachable from E we have 
E' e BSNNI. ■ 

SBSNNI is easily verifiable, as BSNNI is so; moreover, we can use it in order to 
check that a system is BNDC because of the following result. 

Proposition 6. SBSNNI C BNDC 

Proof. Let if be a system and II a high level process. Let i? be a relation 
defined as follows: {E' \ Actn, {E' \ II') \ Actn) € R, for all E' ,11' such that 
E ^ E' and U U' . We want to prove that if E is SBSNNI then R is 

a weak bisimulation up to (see [50]). There is only one non trivial case: 
{E' I il') \ Actn ^ {E" I n") \ Actn- As there exists h € Actn such that 
E' E" , then E' /Act h ^ E" /Actn- By hypothesis, E' G BSNNI hence we 

have E' /Act H E' \ Actn and so there exists an agent E'" such that E' \ 

Actn E'"\ActH and E'"\ActH E" /Actn - By hypothesis, E" G BSNNI 

hence we also have that E" /Actn E"\ActH and so E'"\ActH ~b E"\ActH- 
Since {E" \ Actn, {E" \ II") \ Actn) G R and E'" \ Actn ~b E" \ Actn then 
i? is a bisimulation up to . 

Now we have that E \ Actn (A | El) \ Actn for all II G £h- Since 
E G BSNNI, then E/Actn ~b E/Actn- Therefore E/Actn ~b {E \ II)\ActH- 
This means that E G BNDC. 

The inclusion is strict because agent E = l.h.l.O + l.O + l.l.O is BNDC but 
not SBSNNI. ■ 

The next theorem states that SBSNNI is compositional, i.e., preserved by the 
parallel and the restriction operators. This is useful in the automatic check of this 
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property because it allows to check it directly on the subsystems thus reducing 
the exponential explosion of the states due to all possible interleavings of parallel 
systems. We will study this in details in the next section. Similar results of 
compositionality hold for NNI and SNNI [24]. 

Theorem 3. The following hold: 

{i) E,F € SBSNNI (E\F) € SBSNNI 
(ii) E e SBSNNI, LCC=^ E\Lg SBSNNI 

Proof. We need the following: 

Lemma 1. {E\F)/ActH E / ActnlF/ Actn ■ 

Proof. Consider the following relation: {{E'\F')/ActH, E' / ActulF' / Actn) G R 
if and only \i E ^ E' and F => P'. It is easy to prove that i? is a bisimula- 
tion. Indeed the only non trivial case is the synchronization {E'\F')/ActH — > 
{E"\F")IActH which is simulated by E' j Actu\F' / Actu ^ E" / Act h\F" / A ct h- 



Now we can prove the Theorem. 

(i) Consider the relation ((E'jE') \ Actn,E' \ ActnlF' \ Actn) G R for all 
F', F' such that E ^ E' and F ^ F'. If we prove that i? is a weak bisimulation 
up to then, by hypothesis and Lemma 1, we obtain the thesis. We consider 
the only non trivial case: (F'jF') \ Actn ^ {E"\F") \ Actn with E' E" 
and F' F". Since E' /Actn ^ E" /Actn and, by hypothesis, F' G BSNNI, 
we have that 3F'" such that E' \ Actn E'” \ Actn and E” /Actn ~b 
E'" \ActH', finally, by hypothesis, E" G BSNNI, hence we obtain E”'\ActH ~b 
E" \ Actn- Repeating the same procedure for F' we have 3E'”,F'” such that 
E' \ ActH\F' \ Actn E'” \ ActnlF"' \ Actn E" \ Act}{\F" \ Actn- Since 
((F"|F") \ ActH,E" \ Actnl \ G R, then F is a bisimulation up to 

(a) Consider the following relation {{E' /Actn) \ L, (F' \ L)/ActH) G R, for 
all F' such that E ^ E' and for all F C £. If we prove that F is a bisimulation 
up to then, by applying hypothesis and observing that (F' \L)\ Actn ~b 
{E'\A ctH)\L, we obtain the thesis. The only non trivial case is {E' / ActH)\L 
{E" j Act h) \ L with E' F" and h G Actn- By hypothesis, E' G BSNNI 
hence we have that {E' /Actn) \ L (F' \ Actn) \ L and so 3F'" such that 
(F' \ Actn) \L^ (F"' \ Actn) \L:=iB (E'" j Actn) \ L and (F'" \ AcIh) \L 
{E” /Act h) \ L. Obviously, we also have that (F' \L)\ Ac±h (F'" \L)\ Actn 
and so {E'\L) / Actn {E"'\L) /Actn- We briefly summarize the proof: we had 

the synchronization (E' /ActH) \ L ^ {E" / Actn) \ L and we proved that there 
exists E'" such that (F' \ L)/ActH (F"' \ L)/ActH and {E'" / Actu) \ L k:b 
{E” /A ctH) \ L. Since {{E"' /Actn) \ L, (F"' \ L)/ActH) G F then F is a weak 
bisimulation up to «b . ■ 
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It is worthwhile noticing that SBSNNI was not the first sufficient condition 
proposed for BNDC. In [24] we introduced a property stronger than SBSNNI, 
but nevertheless quite intuitive, called Strong BNDC (SBNDC). This property 
just requires that before and after every high step, the system appears to be 
the same, from a low level perspective. More formally we have the following 
definition. 

Definition 14. (SBNDC: Strong BNDC) 

A system E € SBNDC if and only if WE' reachable from E and WE" such that 
E' E” for h e Actff , then E' \ Actn E” \ Actn 

We now prove that SBNDC is strictly stronger than SBSNNI. To this purpose, 
we need the following Lemma 

Lemma 2. if € BNDC E\ Actn \ ActH for all II G £h- 

Proof. It follows immediately from Theorem l.{ii) and Definition 12. ■ 

Proposition 7. SBNDC C SBSNNI. 

Proof. Let if be a system and iJ a high level process. Let i? be a relation defined 
as follows: {E'\ActH, {E' \ II')\ActH) G R, for all if', II' such that E ^ E' and 
n ^ W . We want to prove that if E is SBNDC then i? is a bisimulation up to 
(see [50]). There is only one interesting case: (if' | II')\ActH ^ {E" \ II")\ActH. 
As there exists h G Actn such that E' A if", then E" \ Actn ~b E' \ Actn] 
since {E"\ActH, {E" \ II")\ActH) G R, then (if" | II")\ActH~B E'\ActH- So 
E' \ Actn (if' I il) \ AcIh (i.e., E' G BNDC), for all E' reachable from E. 
As BNDC is stronger than BSNNI (Theorem l.(ii) ), we obtain the thesis. The 
inclusion is strict because agent E = r.l.O + Ll.O + h.l.O is SBSNNI but not 
SBNDC. ■ 

As for SBSNNI, we have a compositionality theorem: 

Theorem 4. The following hold: 

{i) E,E G SBNDC {E\E) G SBNDC, 

(ii) E G SBNDC ^ E\S G SBNDC, if S C C. 

{Hi) E,E G SBNDC {E\\F) G SBNDC 

Proof, (i) It must be proved that VE',E' : E ^ E',F ^ F',VE",F" : (E' | 

E') A (if" I E") with h G Actn, the following holds: (if' | F') \ Acth (if" | 
F") \ Actn. Let R be the relation defined as follows: {{E \ F) \ ActH, {E' j 
F') \ActH) G R,yE,E',F,F'jVich. that E E,E ^ E' ,F ^ F,F ^ F' 
and E \ Actn ^b E' \ ActH,F \ Acth ^b E' \ Actn- It can be easily proved 
that i? is a weak bisimulation (under the hypothesis E,F G SBNDC); there 
is only one interesting case: (if | i^) \ Actn ^ {E" \ F") \ Actn- Thus we 
have that E \ Actn ~b E" \ Actn and F \ Actn ~b F" \ Actn and so {{E" \ 
F")\ActH,{& \F')\ActH)GR. 
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NNI 




Fig. 11. The inclusion diagram for trace-based and bisimulation-based proper- 
ties 



(ii) Observe that {E'\S)\ActH {E”\S)\ActH if and only if {E'\ActH)\S «b 
{E” \ Actn) \ S'. As is a congruence for restriction [-50] the thesis follows 
trivially. 

(in) Trivial from (i) and (ii). ■ 

Figure 11 summarizes the relations among all the trace-based and bisimulation- 
based properties we have presented. 

We end this section with a remark. In the automatic verification of properties, 
it can be very useful to work on a reduced system, i.e., a system equivalent to 
the original one, but with a smaller number of states. In fact, the tool we will 
present in the next section provides a procedure that minimizes the number of 
states, thus reducing a lot the time spent in the verification. In order to see if this 
proof strategy can be used also in our case, we need to prove that if a system E 
is BN DC, then any other observation equivalent system F is BN DC too. Indeed, 
the theorem below shows that this is the case, also for all the other security 
properties we have discussed in this section. 

Theorem 5. If E «b F , then E G X ^ F G X , where X can be NNI, SNNI, 
NDC, BNNI, BSNNI, BNDC, SBSNNI, SBNDC. 

Proof. It derives from the definition of the security properties, observing that 
trace and bisimulation equivalences are congruences with respect to _ \ L and _|_ 
operators of CCS [.50] . It is possible to prove that they are also congruence with 
with respect to - \i L and -jL operators of SPA. For trace equivalence the proof 
is trivial. In the following we prove the closure of weak bisimulation equivalence 
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Fig. 12. The Channel process, a one-bit channel obtained by three processes 
with high level deadlocks 



w.r.t. - \i L and leave to the reader the other similar case of _/L. Let E F; 
we want to prove that E \j L ^b F \j L. Consider a bisimulation R such that 
{E, F) G R] then define the relation P as follows: {E' \j L, F' \j L) G P if and 
only if {E' , F') G R. P is a bisimulation too, in fact if E' \j L E" \j L then 
fi ^ L n I and E' E” . So 3F" such that F' F"; since ^ L H I then 
F' \ j L F" \i L (and vice versa for F' \i L ^ F" \i L). ■ 

3.4 Building Channels by Exploiting Deadlocks 

In Example 6 we have seen that Access -Monitor A is not BNDC because of 
potential high level deadlocks. We said that a deadlock due to high level activ- 
ity is visible from low level users, hence it gives some information about high 
level actions, and cannot be allowed. However, one could doubt that a high level 
deadlock is really dangerous and, in particular, that it can be exploited to trans- 
mit information from high to low. We demonstrate that it is indeed the case by 
simply showing that it is possible to build a 1-bit channel from high to low level 
using systems which contain high level deadlocks. In particular we obtain a 1-bit 
channel with some initial noise (before the beginning of the transmission), using 
three processes with high level deadlocks composed with other secure systems. 

Of the two high level deadlocks of process Access -Monitor-1 we only exploit 
the one due to write requests. So the following method can be applied also to sys- 
tems with only one high level deadlock. Process Channel is reported in Table 10 
where n G {0,1,2}, x,y G {0,1}; {block, unblock, up-write, upstart, input. 
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Table 10. The Channel process which exploits deadlocks 



Channel = (Chjwrite{0) \ Ch^tart(0) \ AM{0) \ AM{1) \ AM (2) \ 
\R\T)\N 

AM{n) Access-Monitor A[check{n) / access-r{Q,Q), 
block(n) /access-w(l, 1), 

unblock{n)/write{l,0)] \ {accessjr, access-W, write, val} 
Ch_write{x) send_write.Ch_write{l) 

+ 

clear -write.Ch-write{0) 

+ 

if 1 = 1 then 

up-write.Ch-write{0) 

Ch-start{0) Ch-write{0)[sendstart / sendjwrite, upstart /up-write, 

clear start /clear -Write] 

R send-write.R 

+ 

cheek{2) .sendstart. 

{check[Q) .output (Q) .R 

+ 

check (1) .output ( 1 ) • -R) 

T block{2).clear-write.up-write.block{0).block{l).Tl 
T1 clear start.unblock(2) .upstart. block{2) .clear -Write, 

input (y).unblock(y). up -write.block(y).Tl 



clear-write, clearstart] C Actn', N = {check, block, unblock, send-write, 
up-write, clear -write, sendstart, upstart, clear start}. 

Channel (see Figure 12) is the composition of three instances of Access 
Monitor (AM(0),AM(1) and AM{2)), two channels from low to high level 
(Ch-write(0) and Chstart(A)), a transmitter and a receiver (T and R). In par- 
ticular AM{n) is an instance of Access -Monitor -1 where we call check{n) the 
reading request of low level users in low object, it is used to check if AM{n) is in 
a deadlock state; block{n) is a writing request by a high level user, it is used to 
block AM{n); finally unblock{n) is a write action and is used to unblock AM{n) 
which was previously blocked with block{n). Ch-write(x) moves to Ch-write{l) 
every time a sendjwrite is executed by the receiver. Ch-write{l) can give to 
T the up-write signal; it also ignores all the send-write signals. Moreover, when 
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Fig. 13. Noise in Channel and C 



clear jwrite is executed by the transmitter this resets the process to Ch_write(0). 
So if R executes sendjwrite and after this, T executes clear jwrite and upjwrite, 
then T will be blocked. Ch_start{Q) is equal to Chjwriteifi) with appropriate 
action relabeling. 

R and T use the monitor AM (2) for synchronization and AM(0), AM(1) 
for transmission. In particular T blocks AM (2) and then it waits for a write 
enable signal {upjwrite). Afterward it blocks also monitors AM{0) and AM{1) 
moving to T1 which is the writing loop; T1 unblocks monitor AM (2) — which is 
the signal for R to start receiving the bit — and waits for a start writing signal 
(upstart). Then it blocks AM (2) again, reads the high level value y, unblocks 
monitor AM(y) (transmitting the value y) and waits for a write enable signal. 
When it receives such a signal, it blocks again monitor AM(y) and moves to T1 
in order to transmit another bit. 

R can always send a writing enable signal moving again to R. Moreover it 
can check if AM (2) is blocked. If such a monitor is not blocked (by T) it sends 
a start writing signal and checks if AM(0) and AM(1) are blocked. If it discovers 
that AM(t), with f = 0 or t = 1, is not blocked, then it gives as output output(t). 
Finally it moves again to R in order to receive the next bit. 

Note that if R executes check(2) before T has blocked monitor AM (2) then 
R will give a non-deterministic output output(x). In fact T and R will synchro- 
nize and start transmitting the 1-bit messages as soon as T will execute block(2) 
blocking AM (2). So we have some random output before the beginning of the 
transmission. It is possible to automatically check that 

Channel C 



where 



C = T.C 

+ 

T.(T.OUtput(0) .C' + T ,OUtput(\) .C' ) 
+ T. (output (0) .C + T. output (A). C') 
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+ T. {output {1).C + T.output{l).C') 

) 

C' input{x) .output{x) .C' 

This automatic check can be done using the CoSeC tool we will present in the 
next section. 

C can move to a 1-bit channel C or can give some non-deterministic output 
(initial noise before the synchronization between T and R). Note that after 
moving to C (the channel is ready to transmit) it will behave as a perfect 1 -bit 
channel (see Figure 13). 

3.5 Comparison with Related Work 

The use of process algebras to formalize information flow security properties 
is not new. In [57] it is possible to find a definition of Non Interference given 
on CSP [39]. It looks like SNNI with some side conditions on acceptable low 
level actions. This definition is recalled in [4], where a comparison with another 
information flow property is reported. 

More recent results based on the CSP model are contained in [56], where the 
authors introduce some information flow security properties based on the notion 
of deterministic views and show how to automatically verify them using the CSP 
model checker FDR [55]. 

The most interesting property is lazy security {L-Sec) which, however, re- 
quires the absence of non-determinism in the low view of the system (i.e., when 
hiding high actions through interleaving) and for this reason we think it could 
be too restrictive in a concurrent environment. For example, all the low non- 
deterministic systems - such as E = l.li + I.I 2 ~ are considered not secure. In 
this section we compare those properties with ours using a failure-equivalence 
version of BNDC, called FNDC (see also [18] for more details). The main re- 
sult is that BNDC restricted to the class of low-deterministic and non-divergent 
processes is equal to L-Sec. 

Here we give a definition of failure equivalence which does not correspond 
completely to the original one [39]. Indeed, it does not consider possible diver- 
gences but this is not a problem since our comparison will focus on the class of 
non-divergent processes. We prefer this definition because it is very simple and 
is implied by 

V 

We need some simple additional notations. We write E to indicate that 

$E' such that E E' and E ^ with K <Z C stands for Wp G K,E 

Definition 15. If "/ G T{H) o,fter executing 7 , E can refuse all the ac- 

tions in set X C C, then we say that the pair ( 7 , X) is a failure of the process E. 
Formally we have that: 
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When failures(E) = failures(F) we write E E (failure equivalence). ■ 

We identify a process E with its failure set. So if (7,-^) S failures (E) we write 
(7,X) € E. Note that 7 S T{E) if and only if (7,0) G E. So E E implies 
E E. 

We also have that E KSp E implies E rup F\ 

Proposition 8. E F implies E F. 

Proof. Consider E F and (7,^) G E. We want to prove that (7,X) G F. 

Since (7, X) G E we have that 3E' such that E E' and E' 7^. By definition 
of we know that since E E' then F F' and iH' F' (it is sufficient 
to simulate every step of the execution E E'). Suppose by contradiction that 
G X such that F' ^7 F” . Then, by definition of and since E' F' , 

we obtain that E' E” but this is not possible since E' We obtain that 

F' ^ and so (7,^) G F. The symmetric case can be done for every {'j,X) G F 
which must belong also to E. ■ 



Lazy Security We now report the lazy security property [56] and we show 
that it can only deal with low-deterministic processes, i.e., processes which have 
a deterministic behaviour with respect to low level actions. Here we do not 
consider the eager security property (introduced in [56] to deal with output 
actions) since it supposes that high level actions happen instantaneously while 
in SPA, which has synchronous communications, both input and output actions 
can be delayed by users. We start with a formal definition of determinism. 

Definition 16. E is deterministic (E G Det) if and only if whenever 7a G 
traces{E) then (7,(0}) ^ E. ■ 

So a process is deterministic if after every trace 7 it cannot both accept and refuse 
a certain action a. We give another characterization for determinism. A system E 
is deterministic if and only if whenever it can move to two different processes E' 
and E" executing a certain trace 7, such processes are failure equivalent. 

Proposition 9 . E G Det if and only if for all 7 G traces {E) we have that 
E^E', E^ E" implies E' PSp E" . 

Proof. (^) Let E G Det, E ^ E\ E ^ E" and {5,K) G E' . We want 
to prove that {S,K) G E". Since E E' , we have that (7^, AT) G E. By 
E G Det we obtain that Va G K, jSa is not a trace for E. We also have that S 
is a trace for E"; in fact, if E" can execute only a prefix of 5, i.e. E" => E'" 
with 5 = abp, we have that E can execute trace 706 (through E') and can 
refuse b after 70 (through E”) contradicting the determinism hypothesis. Now, 
since Va G K,"f5a ^ traces (E), we also have that Va G K,5a ^ traces{E") and 
so {5,K) G E". 

(<;=) Trivial. ■ 
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Corollary 1. If E =h- E' and E G Det then E' G Det. 

Proof. We have to prove that E' E" and E' E'” implies E" E'" . 

Consider E E" and E E'” then by i? G Det we have that E” E”' . 



In the following we denote with SHIP’ the interleaving without communica- 
tion between agents E and F. It can be expressed in SPA as {E\A/C{E)] \ 
E[B/C{E)])[C{E)/A,C{F)/B] where A, S C £, A n S = 0 and A/C{E) is a bi- 
jective function which maps all the actions executable by E into actions of A, 
with C{E)!A as inverse (the same holds for B/C{F) and C{F)/B). This ex- 
pression means that the actions in E and F are first relabelled using the two 
disjoint sets A and B, then interleaved (no communication is possible) and finally 
renamed to their original labels. 

Recall that a process is divergent if it can execute an infinite sequence of 

def 

internal actions r. As an example consider the agent A = r.A -|- 6.0 which can 
execute an arbitrary number of r actions. We define Nondiv as the set of all the 
non-divergent processes. 

We can now present the lazy security property [56]. This property implies 
that the obscuring of high level actions by interleaving does not introduce any 
non-determinism. The obscuring of high level actions of process E by interleaving 

is obtained considering process E\\\RUN h where RUN h J^h^Actn h.RUN h- 

In such a process an outside observer is not able to tell if a certain high level 
action comes from E or from RUN p. 

L-Sec also requires that E\\\RUN p is non-divergent. ® This is equivalent to 
requiring that E is non-divergent, because RUN p is non-divergent and the ||| 
operator does not allow synchronizations (which could generate new r actions) . 

Definition 17. E G L-Sec E\\\RUN h & Det H Nondiv . ■ 

In the following we want to show that L-Sec can only analyze systems which are 
low-deterministic, i.e., where after any low level trace 7 no low level action I can 
be both accepted and refused. The low-determinism requirement is not strictly 
necessary to avoid information flows from high to low level. So, in some cases, 
L-Sec is too strong. As an example consider the following non-deterministic 
system without high level actions: E LP.O -|- l.V'.O. It is obviously secure but 
it is not low-deterministic and so it is not L-Sec. Formally we have that: 

Definition 18. E is low- deterministic (E G Lowdet) iff E\ Actn G Det. ■ 
The following holds: 

Theorem 6. L-Sec C Lowdet. 

® Note that in [56] the non-divergence requirement is inside the deterministic one. This 
is because the authors use the failure-divergence semantics [10]. In this work we use 
the failure equivalence which does not deal with divergences. So, in order to obtain 
exactly the L-Sec property, we require the non-divergence condition explicitly. 
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Fig. 14. Failure based and bisimulation based properties 



Proof. Let E e L-Sec. Consider a trace 'ya of E \ Actn and suppose that 
(7, {a}) G E\ActH- So there exists E' such that E\ActH E'\ActH and such 

a 

that E' \ Actn yA. Since RUN h cannot execute the low level action a then we 

have that E'\\\RUN h ^ and so (7, {a}) G E\\\RUN h because E\\\RUN h 
i?' 1 1 1 i? UN H ■ Since 7a is a trace for E \ Actn then it is also a trace for 1 1 1 i? UN h 
and we obtain that E\\\RUN h is not deterministic, contradicting the hypothesis. 
So (7, {a}) ^ E \ Actn and E G Lowdet. ■ 

Failure Non Deducibility on Compositions Now we define the failure based 
security properties by simply substituting with in all the bisimulation 
based properties previously defined. 

Definition 19. (Failure based properties) 

(i) E G FNDC 77 E/ActH (E I 7J) \ Actn, for all 7T G Eh! 

(ii) E G FSNNI 77 E/ActH E\ Actn; 

(Hi) E G SFSNNI 77 WE' such that : E =h- E' we have E' G FSNNI . ■ 

Since bisimulation equivalence is stronger than failure equivalence, it can be 
proved that each of these new property is weaker then its corresponding bisim- 
ulation based one. E.g. BNDC C FNDC. Moreover we prove that some of the 
inclusion results we have for bisimulation based properties can be extended also 
to these new properties. 

Theorem 7. SFSNNI C FNDC C FSNNI. 

Proof. {SFSNNI c FNDC) Let E be a SFSNNI process. We have to prove 
that {E\n) \ Actn E/Actn for every high level process II. 

We first prove that {'y,K) G {E\II) \ Actn implies {'y,K) G E/Adn. Consider 
{■y,K) G {E\n) \ Actn, then 3E',II' such that {E\II) \ Actn =7 {E'\II') \ 
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K K 

Actn 7^- Hence E'\ActH 7^ because traces {E'\ Act h) C traces{{E'\lJ')\ActH)- 

K 

Now, since E e SFSNNI then E' \ Actu E' /Actn] hence E' /Actn 7^. Note 

that E/Actn E'/Actn, hence (7, itT) £ E/Actn- 

We now prove that {"f,K) G E/Actn implies (7, if) G {E\II) \ Actn- Consider 
G E/Actn- By hypothesis we have that ("f,K) £ E \ Actn and so 3E' 

such that E \ Actn E' \ Actn 7^- Since E £SFSNNI then E'/Actn 7^- 

K 

Hence we also have that {E'\F[) \ Actn ^ because traces{{E'\F[) \ Actn) C 
traces {E' /Actn)- Since we have that E \ Actn E' \ Actn then {E\II) \ 
Actn {E'\F[) \ Actn and so {"f,K) £ {E\F[) \ Actn- 

(d.0f 

The inclusion is strict because agent E = l.h.l.0 + Z.O + l.l.O is FNDC but not 
SFSNNI. 

{FNDC C FSNNI) It is sufficient to consider 77 = 0. We have that (7?|0) \ 
Actn E\ Actn and so, since (i?|0) \ Actn E/Actn we have E/Actn 
E \ Actn ■ 

def 

The inclusion is strict because agent E = l.h.l.h' .1.0 + Z.O + l.l.l.O is FSNNI but 
not FNDC. m 

Figure 14 summarizes the inclusions among the presented security properties. 
It can be drawn using the previous inclusion results and the following remarks: 
BNDC 2 SFSNNI, in fact agent 77.70 + 70 + 7/.0 is BNDC but not SFSNNI; 
we also have that BSNNI % FNDC because of agent h.Lh' .10 + 7/.0; finally 
SFSNNI % BSNNI because of agent h.l.{l'.0 + 770) + IV .0 + IV ' .0. 

The next theorem shows that under the low-determinism assumption the 
properties SFSNNI and FNDC collapse into the same one. We need the following 
Lemma. 

Lemma 3. If E, E £ Det, E E' , E E' and E Kip E then E' Kip E' . 

Proof. We prove that if {5,K) £ E' then (S,K) £ E' . Let (S,K) £ E' . Then 
(715, K) £ E and hy E KSp E we obtain that (715, K) £ E. So 3E" , E'” such that 

E =7 E" =+■ E'" 7^, hence {S,K) £ E" . Since E £ Det then by Proposition 9 
and hypothesis we have that E” Kip E' and so {6, K) £ E' . We can prove in the 
same way that if (i5, K) £ E' then ((5, K) £ E' . So E' Kip E' ■ 

Theorem 8. FNDC n lowdet C SFSNNI. 

Proof. Since FNDC C FSNNI and E £ FNDC, we have that E \ Actp Kip 
E/Actp. By E G lowdet we obtain E/Actn £ Det. Now consider E E' . 
We have to prove that E' /Act h Kip E' \ Actn- Let 77' be the high level process 
which executes exactly the complement of the high level projection of 7, i.e. 
the complement of the subsequence of 7 composed by all the high level actions 

in 7. If 7' is the low level projection of 7 we have that (7f|77') \ Actp 

(7?'|0) \ Actn E' \ Actn- Since E E' then E/Actp E' /ActH- By 

hypothesis we have that (77|77') \ Actp ~f E/Actn- Since E/Actp £ Det then, 
by Lemma 3, we have that E' /ActH ~f (F-^lO) \ Actn Kip E' \ Actn- ■ 
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Corollary 2. FNDC n Lowdet = SFSNNI n Lowdet. 

Proof. Trivial by Theorems 8 and 7. ■ 



Comparison We now show that under the low-determinism and the non- 
divergence assumption the BNDC property is equal to L-Sec. We start proving 
this result for FNDC. 

Theorem 9. L-Sec C SFSNNI. 

Proof. Let E S L-Sec. Then we have to prove that if E E' then E' \ 
Actn ~F E' j Act H- We first prove that if (<5, iC) S E'/Actn then {5,K) e 
E' \ AcIh. Consider {6,K) € E' /AcIh. Then we have that 3E" such that 

E' /Act}j =i> E" ! Act FI 7^. 

Now we want to prove that i5 is a trace also for E' \ Actn. Let S = S 1 S 2 ... Sn 

and consider the execution E'/Actn E'^/Actn E" /Actn. Sup- 

pose that 8i is the first action in i5 that E'/Actn is not able to execute. In other 
words we have that 

E' \ Actn E'l \ Actn \ Actn 7 ^ 

This means that in order to execute 5i, process E'^_^/ Actn executes some hidden 
high level actions hi . . . h^. So jf execute such high level ac- 
tions with RUN n we obtain that E\\\RUN n E'^_i\\\RUN n. Since 

Si 

\ Actn 7 ^ and 6i € Acte then we obtain that . . . 6i-ihi . . . hk, € 
E\\\RUN n . Moreover, if we execute actions hi...hk with E'^_i we have that 

E\\\RUN n and so .. .5i-ihi .. .h^di is a trace 

for E\\\RUN n- This means that ^ Det hence E ^ L-Sec. We obtain 

a contradiction, so no Si can be refused by E' \ Actn and (5 is a trace for such 
process. So we have that E' \ Actn E'" \ Actn. 

Now we want to prove that (5, K) G E'\ Actn. Let E' \ Actn E'" \ Actn 
and suppose that E'" \ Actn can execute a certain action a G /L n Act^ (the 
actions in isT n Actn cannot be executed by such process) then y(5a is a trace for 
E\\\RVN n ■ Now consider the sequence S' obtained by adding to S all the high 
level action executed by E' in order to reach E" in the transition E'/Actn 
E" /Actn\ i.e. E' E" . Then we will have that E'\\\RUN n E"\\\RUN n 

K a 

and since E" /Actn 7 ^ then E"\\\RUN n 7 ^ and so (7(5', {a}) G E\\\RUN n . Now 
if ^Sa is a trace for E\\\RUN n then also ^S'a is, and so, again, we obtain that 

^ Det and E ^ L-Sec. Hence E'" \ Actn 7 ^ for every a G K and so 
{S,K) G E'\Actn. 

Now we prove that if (<5, iL) G E' \ Actn then (5, iL) G E'/Actn. Suppose 

o K 

{S, K) G E'\Actn. Then we have that 3E" such that E'\Actn => E"\Actn 7 ^. 
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Fig. 15 . Relations among properties 

Hence also E' /Actn E" /AcIh- Suppose that E" /Actn can execute a certain 

a G K O AcIl then consider 5 ' obtained by adding to 8 all the high level actions 
executed by E' before a in the transition E' /Act h E" /Act h E'" /Act h, 
i.e., such that 5 'a is a trace for E' . We have that 'jS'a is a trace for E\\\RVN h ■ 
Now, (( 5 , {a}) G E' \ Actn with a G AcLl and so ( 5 , {a}) € E'\\\RUN h which 
implies that ( 5 ', {a}) G E'\\\RUN h and finally (7(5', {a}) G E\\\RUN h- This 

a 

contradict the fact that E G L-Sec and so E” /Actn G K. Hence {S,K) G 

E'/Actn- ■ 

Theorem 10 . SFSNNI n Lowdet n Nondiv C L-Sec. 

Proof. Let E G SFSNNI n Lowdet n Nondiv and ya be a trace for process 
E\\\RUNh- We want to prove that (7, {a}) ^ E\\\RUNh- It trivially holds if 
a G Actn because in such a case it can always be executed by RUN h- So let 

a G Acth- Suppose E\\\RUN h => E'\\\RUN h 7^ and consider the sequence 7' 
obtained removing all the high level actions from 7. Then E/Actn E'/Actn 
and by hypothesis E'/Actn E'\Actn- Since E'\\\RUN n ^ then E'\ Act n 7^ 

a 

and so E'/Actn 7^ and (7', {a}) G E/Actn- Since E G SFSNNI we obtain 
that (7', {a}) G E \ Actn- Now 7a is a trace for E\\\RUN n and so 7'a must 
be a trace for E/Actn this means that 7'a is also a trace for E \ Actn- Since 
E G Lowdet then E\Actn is deterministic. However we found that 7'a is a trace 
for E\Actn and (7', {a}) G E\Actn obtaining a contradiction. So E'\\\RUN n 
cannot refuse a and (7, {a}) ^ E\\\RUN n- Hence E\\\RUN n G Det and since 
E G Nondiv we also have that E\\\RUN n G Nondiv ■ 
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Corollary 3. SFSNNI H Lowdet H Nondiv = L-Sec. 

Proof. By Theorems 6 and 9 and by Definition 17 we find that L-Sec C SFSNNI 
n Lowdet n Nondiv. Finally by Theorem 10 we obtain the thesis. ■ 

Note that by Corollary 2 we also have that FNDC n Lowdet C Nondiv = L-Sec. 
Now we show that this result also holds for SBSNNI and BNDC. We first prove 
that for deterministic processes fnp becomes equal to 

Proposition 10. E G Det, E K.p F E F. 

Proof. If if G Det and E Kip F we also have that F G Det. Now it is sufficient 
to consider the relation R C S x £ defined as follows: (if', if") G i? if and only 
if : if if', E if". It is easy to show that i? is a weak bisimulation. ■ 

Finally, the following holds. 

Theorem 11. BNDC C Lowdet n Nondiv = SBSNNI n Lowdet C Nondiv = 
L-Sec. 

Proof. (SBSNNlnLowdetnNondiv = L-Sec). We have that SBSNNlnLowdetD 
Nondiv C SFSNNI n Lowdet n Nondiv because SBSNNI C SFSNNI. So by 
Theorem 10 SBSNNI n Lowdet C Nondiv C L-Sec. 

Now we prove that L-Sec C SBSNNI H Lowdet H Nondiv. If if G L-Sec then 
by Corollary 3 we have that E G SFSNNI n Lowdet C Nondiv. So Vif' such 
that : E E' we have E' \ Actp E' /Act h with E \ Actn G Det. In 

particular we also have that E \ Actp ~p E/ActH and since E \ Actn G Det, 

we obtain that E/Actn G Det. Note that E/Actp E' /Act p where 7' is 
the sequence obtained removing all the high level actions from 7. Hence, by 
Corollary 1, E' /Actp G Det. Finally, by Proposition 10 we obtain that E' \ 
Actp Kip E' /Act p. 

(BNDC nLowdetn Nondiv = SBSNNI n Lowdet H Nondiv) Trivial by SBSNNI C 
BNDC C FNDC and since SBSNNI H Lowdet C Nondiv = L-Sec = FNDC C 
Lowdet n Nondiv. ■ 

Figure 15 summarizes the relations among various properties and conditions. We 
have shown that BNDC and SBSNNI are equal to L-Sec when dealing with low- 
deterministic and non-divergent processes. In the next section we will introduce 
the CoSeC tool which is able to automatically check the SBSNNI property over 
finite state agents. This implies that for low-deterministic, non-divergent and 
finite-state processes it is possible to use the CoSeC in order to verify also the 
L-Sec property. In [56] it is shown how to use the FDR tool [55] to check the 
L-Sec property. It would be interesting to compare the performance of FDR and 
CoSeC for the verification of such a property. 

We also want to point out that SBSNNI n Lowdet can extend in a fair 
manner the L-Sec property to divergent processes. L-Sec assumes that processes 
cannot diverge. The semantics used by authors to define L-Sec is the failure- 
divergence one [10]. Failure-divergence semantics gives a so-called catastrophic 
interpretation of divergences, since in the presence of divergences a process may 
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Fig. 16. The inclusion diagram for trace-based security properties 



show any behaviour. We have already seen this problem when we used testing 
equivalence for the definition of our properties. On the other hand bisimulation 
gives a fair interpretation of divergences by assuming that an infinite loop of 
internal actions will be taken a finite number of times, i.e., soon or later we 
will exit from the loop. This is useful, for example, if we want to model a fair 
communication media, where a r-loop represents the unbounded but finite losses 
of messages. The property SBSNNI n Lowdet can be seen as an extension of 
L-Sec which gives a fair interpretation of divergences. 

A good reference about modelling NI in CSP can be found in this volume [58] . 
In such a paper, a new notion based on power bisimiilation is also proposed. We 
intend to compare it with our bisimulation-based properties with the aim making 
our classification as much complete as possible. 

3.6 Other Security Properties 

In [24] we have compared our properties with a number of existing proposal. Here 
we just report the diagram (Figure 16) of the relations among such properties and 
we give the bibliographic references to them. In particular, TNDI derives from 
Non Deducibility on Inputs [62] , Its-Correctability comes from Correctability [41], 
Its-FC is Forward- Correctability [41], Its-RES is a version of Restrictiveness [48]. 
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Fig. 17. Structure of the CoSeC 



Moreover NNIIT is NNI where we require that systems are input total. This 
means that in every state the system must be able to accept every possible 
input by the environment. The aim of this (quite restrictive) condition is to 
prevent users from deducing anything about the state of the system, even if 
they observe the inputs the system accepts. All the properties included in NNIIT 
requires this condition over input actions. NDCIT is NDC with input totality. 
Finally NDC// and NDCmIT are parametric versions of NDC where the high 
level user can exploit only the actions in sets H and M to communicate with 
the system. Table 11 reports all the needed counterexamples which differentiate 
the properties. For more details, please refer to [24]. 

4 The Compositional Security Checker 

In this Section we briefly describe the CoSeC structure and architecture. Before 
giving this description, we want to informally justify why the theory developed so 
far should be equipped with a tool. First of all, we need a tool to practically check 
the examples; even for small problems, the state space grows quite beyond our 
human ability to manage it. A tool is also useful to help intuition on what flaws 
these security properties really capture; only through the tool we can analyze 
easily a large number of examples, and refine our understanding of the security 
properties and of the tractability of validating them. Finally, a tool gives an idea 
of which kind of verification techniques engineers should become acquainted 
with in the future to certify their products (e.g., security protocols). As we will 
show in the next sections, the CoSeC tool has been obtained by modifying the 
Concurrency Workbench [14]. Part of the material contained in this Section has 
been published in [26,32,25]. 

4.1 Input-Output and Architecture 

The inputs of CoSeC are concurrent systems expressed as SPA agents. The 
outputs are answers to questions like: “does this system satisfy that specific 
security property ?”. The structure of CoSeC is described in Figure 17. In detail, 
the tool is able: 
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Table 11. The inclusion table for trace-based security properties 





NNI 


NDC 

SNNI 


TNDI 


Its-RES 


Its-cor. 


Its-FC 


NDCh 


NNIIT 

NDCIT 


NDCmIT 


NNI 


= 


8 


2 


2 


2 


2 


9 


10 


10 


NDC 

SNNI 


C 


= 


2 


2 


2 


2 


C 


10 


10 


TNDI 


C 


1 


= 


3 


3 


3 


9 


10 


10 


Its-RES 


C 


1 


C 


= 


C 


C 


9 


c 


c 


Its-cor. 


C 


1 


C 


6 


= 


6 


9 


c 


c 


Its-FC 


C 


1 


c 


5 


C 


= 


9 


c 


c 


NDCh 


7 


7 


7 


7 


7 


7 


= 


10 


10 


NNIIT 

NDCIT 


C 


1 


C 


3 


3 


3 


9 


= 


c 


NDCmIT 


4 


4 


4 


4 


4 


4 


3 


4 


= 



Let T[x,y] be the table element contained in row x and column y. If T[x,y] G {=, C} 

then xT[x, y]y. If T[x, y] — n then the agent n below is in x and is not in y. In the 

following Uq represents the Input-Total empty agent: TIo = X^ig/*-77o. 

1) Z = i-Z + h.Z' and Z' = 

2) h.LO + 1.0 + I'.Q _ 

3) Z = LZ + h.[Uo + l-IIo) 

4) Z = Y2i£i + h.{IIo + l-IIo) with h ^ M VJ M 

5 ) z = ^\^ii.z + lno + h.no 

6) Z = i-Z + h.Z' + h' .Z" and Z' = 77o + h.Z' + Li7o and 

z" = + h.n^ + i.n^ 

7) h.LO with h^HuH 

8) h.l.O 

9) Z = X]ig_r i-Z + h.Z' and Z' = ^ i.Z' + LUo with hG HuH 

10 ) 0 * 
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Fig. 18 . CoSeC architecture 



— to parse SPA agents, saving them in suitable environments as parse trees; 

— to give a semantics to these parse trees, building the corresponding rooted 
labelled transition systems (rlts for short); this phase terminates only if the 
SPA term generates a finite LTS. 

— to check if an agent satisfies a certain security property; the routine im- 
plemented for this purpose verifies the equivalence of two particular agents 
modeled as rlts. In this way, future changes to the language will not com- 
promise the validity of the core of the tool. 

The CoSeC has the same general architecture of the CW [14]. In its implementa- 
tion we have decided to exploit the characteristic of versatility and extensibility 
of CW. In particular CoSeC maintains the strongly modular architecture of CW. 

Figure 18 shows the architecture of CoSeC. The modules of the system have 
been partitioned in three main layers: interface layer, semantic layer, analysis 
layer. In the interface layer we have the command interpreter. It allows us to 
define the agents and the set of high level actions; it also allows to invoke the 
security predicates and the utility functions on the behaviour of an agent. Then 
we have a parser which recognizes the SPA syntax of agents and stores them 
as parse trees in appropriate environments. The partition of the set of visible 
actions in the sets of high and low level actions has been obtained by defining the 
set of high level actions; by default, all the other possible actions are considered 
at low level. Then we have defined a function that, according to the operational 
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semantic rule of SPA, provides all possible transitions for an agent. This function 
allows the construction of the lts associated with an agent. 

In the semantic layer, CoSeC uses two transformation routines to translate 
LTSs into deterministic and observation graphs respectively. Since they both 
refer to processes modeled as LTSs, they have been imported from CW in CoSeC 
without any modification. 

In the analysis layer, CoSeC uses a routine of equivalence and one of mini- 
mization that belong to the analysis layer of CW. These are a slight modifica- 
tion of the algorithm by Kanellakis and Smolka [42] which finds a bisimulation 
between the roots of two finite state LTSs by partitioning their states. It is inter- 
esting to note that a simple modification of this algorithm can be used to obtain 
the minimization of a finite state lts. 

4.2 Checking the Information Flow Properties 

Here we describe in details how the verification of Information Flow Properties 
proceeds. As we said before, we have properties which are in the following form: 

E is A-secure if and only if Cx [E] « Vx [E] . 

We have seen for SNNI that Cx[—\ = — \ Actn and Vx[—] = —/AcLh- Hence, 
checking the A-security of E is reduced to the “standard” problem of checking 
semantic equivalence between two terms having E as & sub-term. 

In the following we briefly explain how the system works in evaluating se- 
curity predicates NNI, SNNI, NDC, BNNI, BSNNI, SBSNNI, and we discuss 
about their computational complexity. CoSeC computes the value of these pred- 
icates over finite state agents (i.e. agents possessing a finite state lts), based on 
the definitions given in Section 3 that we report below in CoSeC syntax (for ease 
of parsing, in CoSeC the hiding and input restriction operators are represented 
by ! and ?, respectively.): 

E e NNI ^ ElActn {ElActH)\ActH 
E e SNNI = NDC ^ ElActn E\ Actn 

E € BNNI ^ ElActn {ElActn)lActn 
E e BSNNI ^ ElActn ^n E\ Actn 
E e SBSNNI ^ E' e BSNNI, WE' reachable from E 

As for CW, the inner computation of the CoSeC follows three main phases. 

Phase a) (the same for all predicates) CoSeC builds the rltss of the two agents 
of which it wants to compute the equivalence. For example in the case of NNI, 
CoSeC computes the transition graph for {ElActn)lActn and ElActn- In 

An observation graphs [14] is obtained by obscuring the precise amount of internal 
computation. In particular the edges of the LTS are modified in order to reflect the 
relation defined as: n n' n n' and n n' n ==> n' . 
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this phase we do not have any particular problem with complexity, except 
for the intrinsic exponential explosion in the number of states of the RLTS 
due to parallel composition. 

Phase b) (This is split into two depending on the semantics requested by the 
security predicate) 

bl: (for predicates NNI, SNNI, NDC) The two rltss obtained in Phase 
a) are transformed into deterministic graphs following the classic subset 
construction (see e.g. [40]). This algorithm has exponential complex- 
ity since it is theoretically possible, in the deterministic graph, to have 
a node for every subset of nodes in the original graph. However, expe- 
rience shows that very often the number of obtained nodes is less than 
the number of nodes of the beginning graph because of the collapsing of 
the r Transitions. 

b2: (for predicates BNNI and BSNNI) The two RLTSs obtained in Phase 
a) are transformed into observation graphs using the classic algorithms 
for the product of two relations and the reflexive transitive closure of 
a relation. This transformation has a O(n^) complexity, in which n is 
the number of nodes in the original graph. 

Phase c) (For all predicates) The general equivalence algorithm [42] is applied 
to the graphs obtained in Phase b). Time and space complexities of this 
algorithm are 0(k * 1) and 0(k + 1) respectively, where I is the number of 
nodes and k is the number of edges in the two graphs. This is not a limiting 
factor in the computation of the observational and trace equivalences. In 
particular, for observational equivalence, in most cases 80% of computation 
time is due to the routine for reflexive transitive closure of Phase b) . 

Since SBSNNI is verified by testing BSNNI over all the n states of the original 
graph, the resulting complexity will be n times the BSNNI complexity. 

It is interesting to observe that the exponential explosion of the number 
of nodes of the transition graphs (Phase a), due to the operator of parallel 
composition, influences negatively the following phases, but it cannot be avoided 
because of its intrinsic nature. A solution to this problem for the predicates NNI, 
SNNI, NDC and SBSNNI could be based on the exploitation of compositional 
properties (see Section 4.5 for more details). 

4.3 A Sample Session 

The style used in specifying SPA agents in CoSeC is the same used for CCS 
agents in CW. For example the command line 

Command: bi A h.'l.'h.A + 'h.'l.A 

Here we use the typewriter style for CoSeC messages (such as the prompt 
“Command:”); the bold style for CoSeC commands and the italic style for the re- 
maining text (such as agents and sets) inserted by users. 
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defines the agent A = h.l.h.A + h.l.A. As in CW the first letter of agents must 
be a capital letter and output actions have to be prefixed by ' . 

We assumed that the set of visible actions C is partitioned in two complete 
subsets AcLh and AcIl of high and low level actions respectively. With the 
command: 

Command: acth h x 

we specify that Actn = {h,' h,x,' x}. In this way we obtain that h,' h,x,' x are 
considered as high level actions and any other action as low level one. 

Now, we can check whether agent A is NNI secure: 

Command : nni A 
true 

CoSeC tells us that A is NNI secure. Now we can check if agent A is SNNI secure 
too: 



Command : snni A 
false 

So A is NNI secure but is not SNNI secure. If we want to know why such 
a system is not SNNI we can use the debugging version of the SNNI: 

Command : d_snni A 
false 

Agent AlActH 

can perform action sequence ’1 

which agent A\ActH 

cannot 

The tool shows a (low level) trace which distinguishes processes A/ Actn and 
A \ Actn- The trace is I which can be executed only by the first one. This can 
be useful to understand why a process is not secure. Finally the command quit 
causes an exit to the shell. 

4.4 An Example: Checking the Access Monitor 

In this Section we use CoSeC to automatically check all the versions of the 
access monitor discussed in Example 6. Since CoSeC works on SPA agents we 
have to translate all the VSPA specifications into SPA. Consider once more 
Access .Monitor A. Table 12 reports the translation of Access JNonitor A spec- 
ification into the CoSeC syntax for SPA. It has been used a new command 
basi which binds a set of actions to an identifier. Moreover, the \ character at 
the end of a line does not represent the restriction operator, but is the special 

In the translation, we use values {/, h} in place of {0, 1} for the levels of users and 
objects in order to make the SPA specification clearer. As an example access jr(l, 0) 
becomes accessjrJil. 
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Table 12. Translation of Access_Monitor_l to CoSeC syntax for SPA 



bi Access_Monitor_l 
(Monitor I 0bject_10 I Object_hO)~L 

bi Monitor 

access_r_hh. (rhO. ’val_hO. Monitor + rhl . ’val_hl .Monitor) + \ 
access_r_lh. ’val_l_err. Monitor + \ 

access_r_hl. (rlO. ’val_hO. Monitor + rll . ’val_hl .Monitor) + \ 
access_r_ll . (rlO . ’val_10 .Monitor + rll . ’val_ll .Monitor) + \ 
access_w_hh. (write_hO. ’who. Monitor + write_hl . ’whl .Monitor) + \ 
access_w_lh. (write_10. ’who. Monitor + write_ll . ’whl .Monitor) + \ 
access_w_hl . (write_hO .Monitor + write_hl .Monitor) + \ 
access_w_ll . (write_10 . ’wlO .Monitor + write_ll . ’wll .Monitor) 

bi 0bject_h0 

’rh0.0bject_h0 + whO . 0bject_h0 + whl . Object_hl 
bi Object_hl 

’rhl . Object_hl + whO . 0bject_h0 + whl . Object_hl 
bi 0bject_10 

’rl0.0bject_10 + wlO . 0bject_10 + wll . Object_ll 
bi Object_ll 

’rll . Object_ll + wlO . 0bject_10 + wll . Object_ll 
basi L 

rhO rhl rlO rll whO whl wlO wll 
acth 

rhO rhl whO whl access_r_hh access_r_hl val_hO val_hl val_h_err \ 
access_w_hh access_w_hl write_hO write_hl 



character that permits to break in more lines the description of long agents and 
long action lists. 

We can write to a file the contents of Table 12 and load it, in CoSeC, with 
command if <filename>. Now we can check that Access J\/Ionitor A satisfies all 
the security properties except SBSNNI using the following command lines: 

Command: bnni Access -Alonitor A 
true 

Command: bsnni Access-Monitor A 
true 

Command : sbsnni Access -Monitor A 

false: ('valJil. Monitor | Object J.1 | Object Jil) \ L 

Note that when CoSeC fails to verify SBSNNI on a process E, it gives as output 
an agent E' which is reachable from E and is not BSNNI. 

So we have found that 



Access -Monitor-1 S BSNNI , BNNI 
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but 



Access Jvlonitor A ^ SBSNNI 



Since we have that SBSNNI C BN DC C BSNNI, BNNI, we cannot conclude 
whether Access-MonitorA is BNDC or not. However, using the output state E' 
of the SBSNNI verification, it is easy to find a high level process II which can 
block the monitor. Indeed, in the state given as output by SBSNNI, the monitor 
is waiting for the high level action 'valJil; so, if we find a process U which moves 
the system to such a state and does not execute the valJil action, we will have 
a high level process able to block the monitor. It is sufficient to consider 77 = 
' access -rJih.Q. Agent {Access-MonitorA\II)\ActH will be blocked immediately 
after the execution of the read request by 77, moving to the following deadlock 
state: 

((ValJiO. Monitor | ObjectJLO | ObjectJiO) \ L | 0) \ Actn 

(this state differs from the one given as output by SBSNNI only for the values 
stored in objects). It is possible to verify that Access.MonitorA ^ BNDC by 
checking that {Access-M onitorA\II) \Actn Access-MonitorA/ Actu using 

the following command: 



Command: bi Pi ' access jrJihA 
Command: eq 

Agent: {Access -Monitor A \ Pi) \ acth 
Agent: Access -Monitor-1 ! acth 
false 



As we said in Example 6, such a deadlock is caused by synchronous communi- 
cations in SPA. Moreover, using the CoSeC output again, we can find out that 
also the high level process 77' = ' access -W -hi. Q can block Access -Monitor-1, 
because it executes a write request and does not send the corresponding value. 
Hence, in Example 6 we proposed the modified system Access -Monitor -5 with 
an interface for each level and atomic actions for write request and value sending. 
We finally check that this version of the monitor is SBSNNI, hence BNDC too: 

Command: sbsnni Access -Monitor -5 
true 



4.5 State Explosion and Compositionality 

In this section we show how the parallel composition operator can increase ex- 
ponentially the number of states of the system, and then how it can slow down 
the execution speed of security predicate verification. This is basically caused by 
the fact that we have all the possible interleaving of the actions executed by the 
parallel processes. In order to avoid this we exploit some results related to the 
compositionality of the proposed security properties. For some of the properties 
we have that if two systems are “secure” also their parallel composition is secure. 
So, the tool has a special feature that decomposes systems in their parallel com- 
ponents and then checks the properties over that components. If both of them 
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Table 13. Number of states and time spent on a SPARC station 5 



agent 


B 


D 


B\D\B 


B\D\D\B 


state number 


3 


3 


27 


81 


time spent 


<1 sec. 


<1 sec. 


~11 sec. 


~270 sec. 



are secure the tool will conclude that also the whole system is secure. Otherwise 
the check will be performed over the whole system. We prove that this method is 
correct and that it terminates. Moreover we show some modular versions of the 
Monitor that can be verified very efficiently with this compositional technique. 

We start with a very simple example. Let us define in CoSeC the two agents B, 
D and the set Actn of high level actions: 

Command: bi B y.a.b.B + a.b.B 
Command: bi D ' a.'b.{x.D + D) 

Command: acth x y 

Let us check now if B and D are SBSNNI secure: 

Command : sbsnni B 
true 

Command : sbsnni D 
true 

We have seen that SBSNNI is a compositional property, so the two agents 
B\D\B and B\D\D\B must also be SBSNNI secure. Hence the verification of 
these two agents could be reduced to the verification of their two basic compo- 
nents B and D only. The time spent in verifying SBSNNI directly on B\D\B 
and B\D\D\B is very long. Using the size command of CoSeC, which computes 
the number of states of an agent, we can fill in Table 13, which points out the 
exponential increase of the number of states and the consequent increase of the 
computation time for verification of SBSNNI . 

CoSeC is able to exploit the compositionality of security properties through 

an algorithmic scheme we are going to present. For a certain compositional 

d©f 

property P this scheme also requires the following condition: ii Z = E and E 
is P-secure then also Z is P-secure. This condition is satisfied by all the above 
presented properties because of Theorem 5. 

Definition 20. (Compositional Algorithm) Let PCS be a set of SPA agents 
such that 

~ E,E' e P^ E\E' e P 
~ E e P,LC c=^ E\L e P 

- E eP,z=^ E^ Z eP 

and let Ap be a decision algorithm which checks if a certain agent E S Sps 
belongs to P; in other words, Ap{E) = true if E Q P, Ap{E) = false otherwise. 
Then we can define a compositional algorithm A'p(E) in the following way: 
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1) if E is of the form E' \ L, then compute Ap(E'); if Ap(E') = true then 

return true, else return the result of Ap{E); 

2) if E is of the form Ei\E 2 , then compute A'p{Ei) and A'p{E 2 ); if Ap{Ei) = 

A'p{E 2 ) = true then return true, else return the result of Ap{E); 

3) if E is a constant Z with Z E' , then return the result of A'p(E'); 

4) if E is not in any of the three forms above, then return Ap[E). ■ 

The compositional algorithm Ap{E) works as the given algorithm Ap{E) when 
the outermost operator of E is neither the restriction operator, nor the parallel 
one, nor a constant definition. Otherwise, it applies componentwise to the ar- 
guments of the outermost operator; if the property does not hold for them, we 
cannot conclude that the whole system is not secure, and we need to check it 
with the given algorithm. 

Note that the compositional algorithm exploits the assumption that prop- 
erty P is closed with respect to restriction and uses this in step 1. This could 
seem of little practical use, as the dimension of the state space for, let say, E is 
often bigger than that of E\L. However, parallel composition is often used in 
the form {A\B) \ L in order to force some synchronizations, and so if we want 
to check P over A and B separately, we must be granted that P is preserved by 
both parallel and restriction operators. 

To obtain the result for A'p{E), we essentially apply - in a syntax-driven 
way - the four rules above recursively, obtaining a proof tree having (the value 
of) A'p{F) as the root and the various (values of) Ap{E)’s on the leaves for 
the subterms if of T" on which the induction cannot be applied anymore. The 
following theorem justifies the correctness of the compositional algorithm, by 
proving that the evaluation strategy terminates and gives the same result as the 
given algorithm Ap{E). 

Theorem 12. Let F G £ps- If the agent E' occurring in step 1 belongs to 
£pp each time the algorithm A'p executes that step, then Ap(F) terminates 
and Ap{F) = A'p{F). 

Proof. First we want to prove that, in computing Ap{F), if the evaluation of 
the given algorithm Hp is required on an agent E, then E belongs to £ps- The 
proof is by induction on the proof tree for the evaluation of Ap{F). The base 
case is when F can be evaluated by step 4; as - by hypothesis - agent F is finite 
state, the thesis follows trivially. Instead, if F is of the form if' \ L, then ~ by 
the premise of this theorem - if' G £ps, and the inductive hypothesis can be 
applied. In step 2, as F = Ei\E 2 , we have that Ei,E 2 £ £fs, and the inductive 
hypothesis can be applied to prove the thesis. Similarly for step 3, as constant Z 
is finite state if and only if the defining agent F' is so. So, when the algorithm 
executes Ap(E) in steps 1, 2, 3 or 4, it always terminates because E £ £ps- 

To complete the proof concerning termination of the compositional algorithm, 
we still have to prove that the inductive evaluation, in steps 1, 2 and 3, cannot 
loop; in other words, that the proof tree for Ap{F) is finite. While it is obvious 
for cases 1 and 2 (no term can be a proper subterm of itself in a finite term) , the 
thesis follows in case 3 because of the constant guardedness condition over SPA 
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agents. It guarantees that the recursive substitution of non prefixed constants 
with their definitions terminates. Hence the computation of A'p[F) ends. 

To prove that the result of the compositional algorithm A'p is consistent with 
the one obtained by the given algorithm Ap, we observe that the four rules above 
guarantee this, using compositionality properties for steps 1 and 2. ■ 

The theorem above requires that - in evaluating A'p{E) - if if is in the form 
E' \ L, then E' must be finite state. In fact, if we consider a finite state system 
E\L such that E ^ Eps, then Ap{E \ L) terminates while A'p{E \ L) possibly 
do not, because it tries to compute Ap{E) on the non-finite state agent E. The 
premise of the theorem above trivially holds for agents in the class of nets of 
automata. 

The CoSeC command c_sbsnni checks the SBSNNI property exploiting com- 
positionality. Let us now compare the compositional algorithm w.r.t. the normal 
one, starting from Access_Monitor_b. The normal verification of the SBSNNI 
property on such a system requires a lot of time (about 16 minutes on a SUNS 
workstation) because of the above mentioned exponential state explosion due to 
parallel composition. We could hope to get a better result using the composi- 
tional algorithm. Table 14 reports the output of the compositional verification of 
Access-MonitorA where the symbols [\] and [ I ] represent steps 1 and 2 of the 
algorithm, respectively. This table shows that the algorithm fails in the verifica- 
tion of SBSNNI over AM and then succeeds in checking the system as a whole. 
Hence, in this case, the compositional technique cannot help reducing the exe- 
cution time. However, we can modify AM in order to obtain a SBSNNI system 
by making (only!) high level communications asynchronous. This can be done 
adding a high level buffer between the monitor and the interface. The resulting 
system is reported in Table 15 where j G {0, 1, err, empty}, L = {r, w, val(l, y)}, 
N = {res, access-T, accessjw} and res(l,y) G ActH,^y G {Q,l, err, empty}, 
while the same actions with 0 as first parameter belong to Actp. Note that we 
have modified the interface so that it is now able to wait until the high buffer is 
filled by the monitor. 

Using the compositional algorithm, system Access-Monitor Jo can be checked 
very efficiently; the verification of SBSNNI takes about 90 seconds (see Ta- 
ble 16). We can also check that Access -Monitor Jo Access -Monitor -6] so, 

as expected, the introduction of the buffer does not modify the behaviour of the 
monitor. This verification requires about 2 minutes. Note that, by Theorem 5, 
we can conclude that also Access -Monitor -5 is SBSNNI, even if a direct check 
takes (as we said) about 16 minutes. 

Access -Monitor -6 represents an example of successful application of the 
compositional checking; nonetheless, this does not mean that we cannot do bet- 

This value and all the following are obtained exploiting also the state minimization 
feature of the tool. 

The reason why it fails on AM is because AM is essentially Access Ji/Ionitor-1 with 
atomic write operations; hence, it is not SBSNNI because of the possible high level 
deadlock of Example 6 caused by synchronous communications. The interface was 
indeed introduced in order to make communications asynchronous. 
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Table 14. Verification of SBSNNI on Access J^onitorJ) with the compositional 
algorithm 



Coiranand: c_sbsnni Access -Monitor A 
[\] Verifying AM I Interf 
[|] Verifying AM 

[\] Verifying Monitor_5 I Qbject_10 I Object_hO 
[|] Verifying Monitor_5 
[|] Failed! 

[\] Failed! 

Verifying directly (Monitor_5 I 0bject_10 I Object_hO)\L 
[|] Failed! 

[\] Failed! 

Verifying directly (AM I Interf) \K 

true 



Table 15. The Access JMonitor-Q 



Access JMonitorA = {AM -6 \ Interf A) \ N 

AM A {{Monitor A \ Object{l,0) \ Object{0,0) 

I hBuf {empty)) \ L)[res{Q, y)/val{0, y)] 
hBuf{j) r^{l, j). hBuf {empty) + val{l, k).hBuf{k) 

Hpf 

Interf A = Inter fA{0) \ Inter fA{l) 

Inter fA{l) ajr{l, x).acceWsZr{l, x). Inter fAjreply{l) 

+ 

ajw{l, X, z).accessjw{l, x, z) .Inter f A{1) 
Inter f A -reply {!) res{l,y). 

{ if y = empty then 
Inter f -6 -reply {1) 
else 

put{l, y).Interf-6{l)) 
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Table 16. Verification of SBSNNI on Access -MonitorJi exploiting composi- 
tionality 



Command: c_sbsnni Access -Monitor A 
[\] Verifying AM_6 I Interf_6 
[|] Verifying AM_6 
[|] Verifying Interf_6 
[|] Verifying Interf_6_l 
[|] Verifying Interf_6_0 

true 



access_r(l,l) 




Fig. 19. The Modular Access JMonitorJI 



ter. Indeed, such a system is not defined in a very modular way and we hope 
that a more modular definition will lead to a more efficient compositional ver- 
ification. In fact, suppose we want to add other objects to Access JMonitor Jo; 
in such a case, the size of AM_6 will increase exponentially with respect to the 
number of added objects. Now we present a rather modular version of the ac- 
cess monitor. The basic idea of this new version (Figure 19) is that every object 
has a “private” monitor which implements the access functions for such (single) 
object. To make this, we have decomposed process Monitor into two different 
processes, one for each object; then we have composed such processes to their re- 
spective objects together with a high level buffer obtaining the SBSNNI-secui'e 
Modh and Modi agents. In particular. Monitor JI{x) handles the accesses to 
object X (x = 0 low, x = 1 high). As in Access-Monitor Jo, we have an interface 
which guarantees the exclusive use of the monitor within the same level and is 
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able to read values from the high buffer. The resulting system is reported in Ta- 



xable 17. The Access-MonitorJ 



Access -Monitor ^7 = {Modh \ Modi \ Inter f -6) \L 

Hpf 

Modh = ((Monitor _7(1) | Object{l,0) \ hBuf (empty)) \ Lh) 
[res{0,y)/val{0,y)] 

Hof 

Modi = {{M onitor -7 (0) \ Object{0,0) \ hBuf (empty)) \ Lh) 
[res(0,y)/val(0,y)] 

M onitor -7 (x) accessjr(l, x). 

( it X < I then 

r(x, y).val(l, y ). Monitor IT (x) 
else 

val(l, er r). Monitor -7 (x)) 

+ 

accessjw(l, x, z). 

( if X > I then 

w(x, z). Monitor -7 (x) 
else 

Monitor J(x)) 



ble 17 where L = {res^access-r^accessjw} and Lh = {r,w,val(l^y)}. Table 18 
reports the output of the (successful) verification of the SBSNNI property for 
Access-M onitor -7 . This task takes about 20 seconds on a SUN5 workstation, 
supporting our claim that a modular definition would help. Moreover, we can 
also check the new version of the monitor is functionally equivalent to the pre- 
vious ones: in about 5 minutes, CoSeC is able to check that Access-Monitor JI 
Access -Monitor -5, and so also Access -Monitor -7 Access-Monitor-6. 

As a final remark, the compositional verification is more convenient only 
when building complex systems as parallel composition of simpler ones. For 
this reason, the tool offers to the user the choice between the normal and the 
compositional verification algorithms. It is up to the user to choose which one 
(s)he thinks could go better, or even to make them work in parallel. 

5 Conclusion 

In this paper we have proposed a formal model for the specification and analysis 
of information flow properties. We have adopted a particular algebraic style in 
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Table 18. Verification of SBSNNI on Access-MonitorJI exploiting composi- 
tionality 



Command: c_sbsnni Access -MonitorJ 
[\] Verifying Modh I Modi I Interf_6 
[ I ] Verifying Modh 
[|] Verifying Modi 
[|] Verifying Interf_6 
[|] Verifying Interf_6_l 
[|] Verifying Interf_6_0 

true 



the definition of such properties. Indeed we have always given properties which 
are parametric with respect to a notion of semantic equivalence. This is useful 
since we can change the discriminating power of a property by simply “plugging 
in” the appropriate equivalence notion. Moreover, in this way we have obtained 
very compact and simple definitions. We have also seen how this algebraic style 
can be very profitable when automatically checking the properties. Indeed we 
can reduce the task of checking a security property to the well studied problem 
of checking the semantic equivalence of two terms of the language. 

We have seen that the main motivation for information flow properties is 
historically bound to system security, in particular to the detection of direct and 
indirect information flows inside a system. However we have obtained a very 
general setting where we can study if a certain class of users, the high level 
users, can in some way interfere with the low level ones. Indeed we have used 
this Non-Interference abstraction in order to model the absence of information 
flow: “if high level users cannot interfere with low level ones then no information 
flow is possible from high to low level” . 

We have tried to convince the reader that the properties we have proposed are 
satisfactory for the detection of information flows inside a system, in particular 
the BNDC property which can also detect flows due to potential high level 
deadlocks. 

In recent papers [28,3], the underlying model has been extended in order 
to deal with time and probability. Once an appropriate semantics equivalence 
has been defined in these new models, the BNDC property has been shown to 
naturally handle the new features of the model. In particular, in such models, 
BNDC has been shown to be able to detect timing and probabilistic convert 
channels, respectively. 

Another aspect we are studying is the possibility of defining a criterion for 
evaluating the quality of information flow properties [33]. We are trying to do 
this by defining classes of properties which guarantee the impossibility of the 
construction of some “canonical” channels. We have seen, for example, that using 
some systems which are not BNDC it is possible to obtain a (initially noisy) 
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perfect channel from high to low level. The aim is to classify the information 
flow properties depending on which kind of channels they effectively rule out. 

We have seen that it is possible to automatically check almost all the prop- 
erties we have presented. Indeed we are still looking for a good (necessary and 
sufficient) characterization of the BNDC property. We have also briefly pre- 
sented the CoSeC tool. In [47], Martinelli has applied partial model checking 
techniques to the verification of BNDC, leading to the implementation of an 
automatic verifier [46] which is able to automatically synthetize the possible 
interfering high-level process. 

As we have stated above, the setting we have proposed is quite general. We 
claim that information flow (or NI) properties could have a number of differ- 
ent applications since they basically capture the possibility for a class of users 
of modifying the behaviour of another user class. This generality has allowed 
to apply some variants of our properties to the analysis of cryptographic proto- 
cols [15,30,29,31], starting from a general scheme proposed in [34]. This has been 
the topic of the second part of the course “Classification of Security Properties” 
at FOSAD’OO school, and we are presently working on a tutorial which will cover 
it [27]. 

This application of NI properties to network security is new to our knowl- 
edge. The interesting point is that they can be applied to the verification of 
protocols with different aims, e.g., authentication, secrecy, key-distribution. We 
have analyzed a number of different protocols, thanks to a new tool interface 
which permits to specify value-passing protocols and to automatically generate 
the enemy [15]; this has also allowed to find new anomalies in some cryptographic 
protocols [16]. 

In [19,20,11,12], a new definition of entity authentication, which is based 
on explicit locations of entities, has been proposed. We are presently trying 
to characterize also this property through information flow. We also intend to 
carry the BNDC theory over more expressive process calculi, like, e.g., pi/spi- 
calculus [2] and Mobile Ambients [13]. This would allow to compare it with 
new recent security properties proposed on such calculi and reminiscent of some 
Non-Interference ideas (see, e.g., [37,35]). 

References 

1. M. Abadi. “Secrecy by Typing in Security Protocols” . Journal of ACM, 46(5) '.749- 
786, 1999. 331 

2. M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The spi 
calculus. Information and Computation, 148(l):l-70, 1999. 331, 392 

3. A. Aldini. “Probabilistic Information Flow in a Process Algebra”. To appear in 
proceedings of CONGUR’Ol, 2001. 391 

4. P. G. Allen. “A Comparison of Non-Interference and Non-Deducibility using CSP” . 
In Proceedings of the Fourth IEEE Computer Security Foundations Workshop, 
pages 43-54, Franconia, New Hampshire, June 1991. 368 

5. D. E. Bell and L. J. La Padula. “Secure Computer Systems: Unihed Exposition 
and Multics Interpretation”. ESD-TR-75-306, MITRE MTR-2997, March 1976. 
332 



Classification of Security Properties 393 



6. J. A. Bergstra and J. W. Klop. “Algebra of Communicating Processes with Ab- 
straction”. Theoretical Computer Science, 37:77-121, 1985. 356 

7. P. Bieber and F. Cuppens. “A Logical View of Secure Dependencies”. Journal of 
Computer Security, 1(1):99-129, 1992. 333 

8. C. Bodei, P. Degano, F. Nielson, and H. Riis Nielson. “Static Analysis of Processes 
for No Read-Up and No Write-Down”. In proc. of 2nd FoSSaCS’99, Amsterdam, 
March 1999. Springer. 331 

9. S. D. Brookes, C. A. R. Hoare, and A. W. Roscoe. “A Theory of Communicat- 
ing Sequential Processes” . Journal of the Association for Computing Machinery, 
31(3):560-599, July 1984. 340, 348, 353 

10. S. D. Brookes and A. W. Roscoe. “An Improved Failures Model for Communicating 
Processes”. In Proceedings of the Pittsburgh seminar on concurrency, pages 281- 
305. Springer- Verlag, LNCS 197, 1985. 370, 375 

11. C. Bodei, P. Degano, R. Focardi, and C. Priami. “Authentication via Localized 
Names”. In Proceedings of CSFW’99, pages 98-110. IEEE press, 1999. 331, 392 

12. C. Bodei, P. Degano, R. Focardi, and C. Priami. “Primitives for Authentication 
in Process Algebras”. Theoretical Computer Science, to appear, 2001. 331, 392 

13. L. Cardelli and A. Gordon. “Mobile Ambients”. In proceedings of FoSSaCS’98, 
pages 140-155. Springer LNCS 1378, 1998. 392 

14. R. Cleaveland, J. Parrow, and B. Steffen. “The Concurrency Workbench: a Seman- 
tics Based Tool for the Verification of Concurrent Systems”. ACM Transactions 
on Programming Languages and Systems, Vol. 15 No. 1:36-72, January 1993. 334, 
377, 379, 380 

15. A. Durante, R. Focardi, and R. Gorrieri. “A Compiler for Analysing Cryptographic 
Protocols Using Non-Interference”. ACM Transactions on Software Engineering 
and Methodology, 9(4):489-530, 2000. 392 

16. A. Durante, R. Focardi, and R. Gorrieri. “CVS at Work: A Report on New Fail- 
ures upon Some Cryptographic Protocols” . In proceedings of Mathematical Meth- 
ods, Models and Architectures for Computer Networks Security, pages 287-299, 
St. Petersburg, Russia, May 2001. LNCS 2052. 392 

17. N. Durgin, J. Mitchell, and D. Pavlovic. “Protocol composition and correctness”. 
In proceedings of Workshop on Issues in the Theory of Security (WITS ’00), Uni- 
versity of Geneva, July 2000. 331 

18. R. Focardi. “Comparing Two Information Flow Security Properties”. In Pro- 
ceedings of Ninth IEEE Computer Security Eoundation Workshop, (CSFW’96), 
(M. Merritt Ed.), pages 116-122. IEEE press, June 1996. 348, 368 

19. R. Focardi. “Located Entity Authentication” . Technical Report CS98-5, University 
of Venice, 1998. 392 

20. R. Focardi. “Using Entity Locations for the Analysis of Authentication Proto- 
cols” . In Proceedings of Sixth Italian Conference on Theoretical Computer Science 
(ICTCS’98), November 1998. 392 

21. R. Focardi. Analysis and Automatic Detection of Information Flows in Systems 
and Networks. PhD thesis. University of Bologna (Italy), 1999. 331, 348 

22. R. Focardi and R. Gorrieri. “An Information Flow Security Property for GCS”. 
In Proceedings of the Second North American Process Algebra Workshop (NAPAW 
’93), TR 93-1369, Cornell (Ithaca), August 1993. 348 

23. R. Focardi and R. Gorrieri. “A Taxonomy of Trace-based Security Properties for 
GCS ”. In Proceedings Seventh IEEE Computer Security Foundation Workshop, 
(CSFW’94), (Li Gong Ed.), pages 126-136, Franconia (NH), June 1994. IEEE 
Press. 348 



394 



Riccardo Focardi and Roberto Gorrieri 



24. R. Focardi and R. Gorrieri. “A Classification of Security Properties for Process 

Algebras”. Journal of Computer Security, 3(l):5-33, 1994/1995. 333, 335, 348, 

362, 363, 376, 377 

25. R. Focardi and R. Gorrieri. “Automatic Compositional Verification of Some Se- 
curity Properties”. In Proceedings of Second International Workshop on Tools 
and Algorithms for the Construction and Analysis of Systems (TACAS’96), pages 
167-186, Passau (Germany), March 1996. Springer- Verlag, LNCS 1055. 377 

26. R. Focardi and R. Gorrieri. “The Compositional Security Checker: A Tool for 
the Verification of Information Flow Security Properties” . IEEE Transactions on 
Software Engineering, 23(9):550-571, September 1997. 335, 348, 377 

27. R. Focardi, R. Gorrieri, and F. Martinelli. “Classification of Security Properties 
(Part II: Network Security)”. Forthcoming. 392 

28. R. Focardi, R. Gorrieri, and F. Martinelli. “Information Flow Analysis in a Discrete 
Time Process Algebra”. In Proceedings of 13th IEEE Computer Security Founda- 
tions Workshop (CSFW13), (P.Syverson ed.), pages 170-184. IEEE CS Press, July 
2000. 391 

29. R. Focardi, R. Gorrieri, and F. Martinelli. Message authentication through non- 
interference. In Proc. of 8th International Conference in Algebraic Methodology 
and Software Technology (AMAST), 2000. 392 

30. R. Focardi, R. Gorrieri, and F. Martinelli. “Non Interference for the Analysis 
of Cryptographic Protocols”. In Proceedings of ICALP’OO, pages 744-755. LNCS 
1853, July 2000. 331, 392 

31. R. Focardi, R. Gorrieri, and F. Martinelli. Secrecy in security protocols as non- 
interference. In Workshop on secure architectures and information flow, volume 32 
of ENTCS, 2000. 392 

32. R. Focardi, R. Gorrieri, and V. Panini. “The Security Checker: a Semantics- 
based Tool for the Verification of Security Properties” . In Proceedings Eight IEEE 
Computer Security Foundation Workshop, (CSFW’95) (Li Gong Ed.), pages 60- 
69, Kenmare (Ireland), June 1995. IEEE Press. 377 

33. R. Focardi, R. Gorrieri, and R. Segala. “A New Definition of Multilevel Secu- 
rity”. In proceedings of Workshop on Issues in the Theory of Security (WITS ’00), 
University of Geneva, July 2000. 391 

34. R. Focardi and F. Martinelli. “A Uniform Approach for the Definition of Security 
Properties”. In Proceedings of World Congress on Formal Methods (FM’99), pages 
794-813. Springer, LNCS 1708, 1999. 392 

35. C. Fournet and M. Abadi. “Mobile Values, New Names, and Secure Communica- 
tion”. In Proceedings of the 28th ACM Symposium on Principles of Programming 
Languages (POPL’Ol), pages 104-115, January 2001. 392 

36. J. A. Goguen and J. Meseguer. “Security Policy and Security Models”. In Proceed- 
ings of the 1982 Symposium on Security and Privacy, pages 11-20. IEEE Computer 
Society Press, April 1982. 332, 333, 348 

37. M. Hennessy and J. Riely. “Information Flow vs. Resource Access in the Asyn- 
chronous Pi-Calculus”. In proceedings of ICALP, pages 415-427, 2000. 392 

38. Y. Hirshfeld. “Bisimulation Trees and the Decidability of Weak Bisimulations”. 
Technical report, Tel Aviv University, 1996. 356 

39. C. A. R. Hoare. Communicatinq Sequential Processes. Prentice-Hall, 1985. 336, 
337, 368 

40. J. Hopcroft and J. Ullman. Introduction to Automata Theory, Languages and 
Computation., pages 22-24. Addison- Wesley, 1979. 381 



Classification of Security Properties 395 



41. D. M. Johnson and F. J. Thayer. “Security and the Composition of Machines”. In 
Proceedings of the Computer Security Foundations Workshop, pages 72-89, June 
1988. 333, 376 

42. P. Kanellakis and S. A. Smolka. “CCS Expressions, Finite State Processes, and 
Three Problems of Equivalence”. Information & Computation 86, pages 43-68, 
May 1990. 355, 380, 381 

43. R. Keller. “Formal Verification of Parallel Programs”. Communications of the 
ACM, 19 (7):561-572, 1976. 333 

44. G. Lowe. “Casper: A Compiler for the Analysis of Security Protocols”. Journal of 
Computer Security, 6:53-84, 1998. 331 

45. G. Lowe and B. Roscoe. “Using CSP to detect Errors in the TMN Protocol”. IEEE 
Transactions on Software Engineering, 23(10):659-669, 1997. 331 

46. D. Marchignoli and F. Martinelli. Automatic verification of cryptographic proto- 
cols through compositional analysis techniques. In Proceedings of the International 
Conference on Tools and Algorithms for the Construction and the Analysis of Sys- 
tems (TACAS), 1999. 392 

47. F. Martinelli. “Partial Model Checking and Theorem Proving for Ensuring Security 
Properties”. In Proceedings of the 11th Computer Security Foundation Workshop, 
(CSFW’98). IEEE press, 1998. 361, 392 

48. D. McCullough. “Noninterference and the Composability of Security Properties”. 
In Proceedings, 1988 IEEE Symposium on Security and Privacy, pages 177-186. 
IEEE Computer Society Press, April 1988. 333, 376 

49. J. K. Millen. “Hookup Security for Synchronous Machines”. In Proceedings of 
the Third Computer Seeurity Foundation Workshop III. IEEE Computer Society 
Press, 1990. 333 

50. R. Milner. Communication and Concurrency. Prentice-Hall, 1989. 333, 335, 337, 
339, 340, 343, 344, 361, 363, 364 

51. J. C. Mitchell, M. Mitchell, and U. Stern. “Automated Analysis of Cryptographic 
Protocols Using Mur<;i”. In Proceedings of the 1997 IEEE Symposium on Research 
in Security and Privacy, pages 141-153. IEEE Computer Society Press, 1997. 331 

52. R. De Nicola and M. Hennessy. “Testing equivalences for processes”. Theoretical 
Computer Science, 34:83-133, 1984. 341, 348, 353 

53. L. C. Paulson. “Proving Properties of Security Protocols by Induction”. In 10th 
Computer Security Foundations Workshop, pages 70-83. IEEE Computer Society 
Press, 1997. 331 

54. G. Plotkin. “A Structural Approach to Operational Semantics”. Technical Report 
DAIMI-FN-19, Aarhus University, 1981. 334 

55. A. W. Roscoe. “Model Checking CSP”. In A. W. Roscoe (ed) A Classical Mind. 
Prentice Hall, 1994. 368, 375 

56. A. W. Roscoe, J. C. P. Woodcock, and L. Wulf. “Non-interference through Deter- 
minism” . In Proceeding of European Symposium on Research in Computer Security 
1994 (ESORICS’94), pages 33-53. Springer- Verlag LNCS 875, 1994. 368, 369, 370, 

375 

57. P. Y. A. Ryan. “A CSP Formulation of Non-Interference”. In Proceedings of the 
1990 Computer Security Eoundation Workshop III, Franconia, 1990. IEEE press. 
368 

58. P. Y. A. Ryan. “Mathematical Models of Computer Security”. In this volume. 

376 

59. S. Schneider. “Verifying authentication protocols in CSP”. IEEE Transactions on 
Software Engineering, 24(9), September 1998. 331 



396 



Riccardo Focardi and Roberto Gorrieri 



60. G. Smith and D. M. Volpano. “Secure Information Flow in a Multi-Threaded 
Imperative Language”. In Proc. of POPL, pages 355-364, 1998. 331 

61. L. J. Stockmeyer and A. R. Meyer. “Word problems requiring exponential time”. 
In Proceedings of the 5th ACM Symposium on Theory of Computing, pages 1-9, 
Austin, Texas, 1973. 355 

62. D. Sutherland. “A Model of Information”. In Proceedings of the 9th National 
Computer Security Conference, pages 175-183. National Bureau of Standards and 
National Computer Security Center, September 1986. 333, 376 

63. C. R. Tsai, V. D. Gligor, and C. S. Chandersekaran. “On the Identification of 
Covert Storage Channels in Secure Systems”. IEEE Transactions on Software 
Engineering, pages 569-580, June 1990. 332 

64. J. T. Wittbold and D. M. Johnson. “Information Flow in Nondeterministic Sys- 
tems”. In Proceedings of the 1990 IEEE Symposium on Research in Security and 
Privacy, pages 144-161. IEEE Computer Society Press, 1990. 333 



Author Index 



Cervesato, Iliano 63 

de Capitani di Vimercati, 

Sabrina 137 

Focardi, Riccardo 331 



Gordon, Andrew D 262 

Gorrieri, Roberto 331 

Guttman, Joshua D 197 

Ryan, Peter Y. A 1 

Samarati, Pierangela 137 

Syverson, Paul 63 




